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Figure 1 . Design process overview. 












FOREWORD 


This report deals with the design process for launch vehicles. It extracts information from the 
experience of the authors, their associates, and related literature. The initial sections of the report address 
essential groundwork and fundamentals, and the final sections address guidance for achieving a successful 
design and advancing design process technology. However, the core of the report is the characterization or 
description of the design process itself given in section 4.3. An overview of the process description is 
represented in figure 1 which illustrates the main elements and connections of the process. Main elements 
include compartmentalization/reintegration, subsystem tree, design function planes, discipline functions, 
decision gates, Ixl and NxN diagrams, and the process balancing act. 

A reader concerned specifically with the process description can go directly to section 4.3 for the 
detailed discussion. The description then serves as a basis for (1) understanding the design process and 
how its various elements interact, (2) incorporating subtleties necessary for a successful design, and 
(3) achieving advances in design process effectiveness and efficiency. 
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TECHNICAL PUBLICATION 


LAUNCH VEHICLE DESIGN PROCESS: CHARACTERIZATION, 
TECHNICAL INTEGRATION, AND LESSONS LEARNED 

1. INTRODUCTION 


1.1 Motivation and Approach 

There is a strong need within NASA and the aerospace industry to reduce the cost and improve the 
effectiveness of launching payloads into orbit. Understanding and improving the design process for launch 
vehicles are essential ingredients in obtaining a low cost, effective launch capability. This report addresses 
characterizing, understanding, and improving the launch vehicle design process. It grew out of an initia- 
tive of the former Structures and Dynamics Laboratory at NASA Marshall Space Flight Center (MSFC). 

The goal of this activity is to enable effective and efficient launch vehicle design by (1) providing 
an understanding of the current design process as a basis for improving effectiveness and efficiency and 
(2) providing a design process reference guide for less experienced engineers. This report characterizes 
and clarifies the current design process. It examines common problems encountered and provides guidance 
for effective implementation. It also includes an initial listing of improvements to the current design process 
and initial observations on advanced technologies that might revolutionize the design process. 

Engineering design is a challenging activity for any product. Since launch vehicles are highly 
complex and interconnected and have extreme energy density, their successful design represents a 
challenge of the highest order. 

Most new launch vehicles require very high propulsion efficiency and mass efficiency, have 
significant uncertainties in environmental and system parameters, and involve advanced technologies. 
They have stringent requirements for performance, cost, reliability, safety, operability, and schedule. Meeting 
the design challenge resulting from the combination of the above factors demands the best of engineering 
skill, organization, communication, integration, and judgment. 

The currently accepted design approach to space systems is to compartmentalize the hardware 
subsystems, subsystem design functions, and discipline functions. The substructuring is driven by the need 
to distribute the workload into manageable portions, the need to utilize multiple discipline specialties, and 
the need to capitalize on industrial specialization. The functional characteristics of the subsystems enable 
decoupling which allows for the distribution of the workload to the design functions and allows for the 
utilization of the industrial specialization. Industrial specialization refers to the specific expertise that has 
evolved in industry to provide unique subsystems (e.g., avionics, rocket engines, etc.) and parts 



(e.g., o-rings, transducers, etc.). Achieving the highest quality and lowest cost for a launch vehicle entails 
utilizing this specialized expertise of the industrial base. Industrial specialization also provides hardware 
availability and schedule reduction. The specialization also enhances technology development. Compart- 
mentalization results in two distinct functions: ( 1 ) The design function and (2) the discipline function. The 
design functions are supported and accomplished through the discipline functions. The approach revolves 
around allocating requirements, constraints, etc., to the subsystems, elements, and components. The 
hardware and software are designed and produced through analysis, testing, simulation, and manufacturing 
processes. The design and discipline functions accomplish these tasks. As is true with industrial 
specialization, this compartmentalization focuses specialization and technology development. The 
inherent problem with compartmentalization is that it necessarily creates artificial boundaries in the 
process and organization. These boundaries create the tendency toward sandboxing or territorial syndromes. 
This creates communication problems in properly exchanging interacting parameters and data. These 
boundaries have made it difficult, if not impossible, to establish an ideal, seamless design process. 

When the process works properly and interactions occur among subsystems, design functions, and 
disciplines, design iterations must occur to converge the total system to achieve requirements. Key 
decisions in the iterative design process are based on analysis, simulation, test results, and keen engineering 
judgment. In this method, the system design is accomplished by assembling these separately designed 
subsystems, etc., and iterating or balancing between conflicting outputs. As stated previously, the system 
has evolved along the specialization (competencies) of industry and academia. This standardization and 
specialization result in higher quality and lower cost parts, components, etc. The design process takes 
advantage of these specialties. Design function and discipline function compartmentalization follow from 
standard specialties of universities and design organizations. The approach is applicable in general; 
however, it is usually based on the assumption of weak coupling between the subsystems, design 
functions, and disciplines. If the coupling is not weak, there are more difficulties in allocating 
requirements, communicating, and interacting within the total system. 

It is a generally stated axiom that 80 to 90 percent of design problems are not caused by a lack of 
discipline understanding but are due to a breakdown in communication. As a result, there are risks 
associated with the process that must be assessed and understood. 

First, the higher the performance requirements of a system, the higher the sensitivities and 
interactions. This means extensive emphasis must be placed on allocations, interactions, integration, and 
communications’ reliability; otherwise major problems occur. 

Second, compartmentalization naturally introduces boundaries, setting up the tendency for 
industry and discipline nearsightedness. 

Third, system design must be recognized as a balancing act between the conflicting requirements 
and interactions. 

In summary, ensuring that the current design approach works requires proper attention be given to 
allocating and refining requirements, to understanding sensitivities and interactions, and to ensuring 
technical integration through adequate communication. 
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The first part of the activity reported here is intended to characterize and baseline the launch 
vehicle design process. In section 4.3.1, the process has been characterized by compartmentalizing the 
system into subsystems, with each subsystem having design function planes overlaid with a system design 
function plane. Within each design function plane are the contributing discipline and design activities 
along with output attributes. This description includes both the tasks and how design decisions are made 
fractionally and incrementally and how design decisions are integrated into the total design. For each plane 
a flow diagram is developed for illustrating the various decision gates and a description of top-level 
attributes to be compared with requirements. This approach was developed to characterize the launch 
vehicle detail design stage and can be applied to other design stages; e.g., conceptual and preliminary 
design stages. 

The typical process as practiced currently is referred to herein as the baseline. The characterization 
of the baseline serves as a reference point for refining and improving the present process (evolutionary). It 
also serves as a reference point to develop revolutionary technologies for the design process that could 
produce orders of magnitude jumps in process efficiency and effectiveness. The effort 
reported here is the initial task of determining the essence of the launch vehicle design process. If we are to 
meet the launch capability demands, then breakthrough must occur. 

Utterback in Mastering the Dynamics of Innovation 1 discusses how companies can seize opportuni- 
ties in the face of technological change. Others have dealt with the subject also. Utterback characterizes the 
development of a product in steps. First, the company concentrates on product innovation until it is an 
established product. Second, they concentrate on process improvement. Third, the product is then in a 
specific phase and is firmly established. During this time, the product performance (sales, use) continues to 
rise with minor attention to product or process improvement. As invading technologies or the requirement 
for them come in, the product will accomplish bursts of improvements. However, this is not sufficient to 
save the product as it is, and the invading technologies take over. For example, digital watches replaced the 
Swiss jeweled watch. The manual and electric typewriters were replaced by the word processor. The 
household refrigerator replaced the ice factories. None of these invading technologies were implemented 
by the parent companies. Utterback’s concept, as discussed above, was applied to aerospace as indicated in 
figure 2. So, NASA and the major aerospace industries should follow a three-pronged attack: 

1 . Delineate and baseline the launch vehicle design process 

2. Refine and improve the baseline process — evolutionary 

3. Implement new innovative technologies to advance the process — revolutionary. 
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Stage 1— Innovation; Stage 2— Incremental Improvement; Stage 3 — Burst Improvement 

Time 

Utterback’s Characterization of Product Development: 1 

First Stage: Concentration is on product innovation until it becomes an established product 

Second Stage: Concentration is on process improvement 

Third Stage: Burst improvements in product stimulated by new requirements and new technologies 

Fourth Stage: New technologies take over; e.g., quartz watch, word processor, refrigerator 

Recommendation: 

(1) Work hard to accomplish major burst in the current suboptimum approach, fine tuning it for more efficiency 
in performance, cost, reliability, safety, operability, and scheduling. 

(2) Pursue new technologies that can revolutionize vehicles. 


Figure 2. Product evolution cycle. 
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1.2 Report Overview and Organization 


The results presented in this report characterize and baseline the launch vehicle design processes. 
This was achieved by systematically defining, delineating, and explaining the key features of the design 
process. This overview is intended to illustrate that method via the organization of the report. The 
following is a brief explanation of the various sections of the report. 

1.2.1 Introduction 

This section presents the motivation and goals of this activity. In addition, the complexity of the 
process is explained as well as the challenges. The scope of the effort is delineated, and the process is 
briefly characterized and explained. Utterback’s characterization of product development is introduced to 
reflect the potential impact on the aerospace community. 1 

1.2.2 Process Overview 

A top-level description of the design process is presented to show the connectivity between the 
space transportation system (STS), launch vehicle system and subsystems, design functions/discipline 
functions with compartmentalization and allocation, and the technical integration process. Additionally, a 
thumbnail sketch is presented to delineate concept selection, preliminary design, and detailed design. 

1.2.3 Essentials 

While the design process itself is key to evolving a design, there are also 1 1 essential engineering 
considerations that must be recognized and carefully implemented. These considerations are subtle and 
implicit in the process, but they are of such importance that we have called them “essentials.” These 
essential engineering considerations are as follows: basis of good engineering; constraints; derived 
requirements; formal design criteria; categories of modeling/activities; analyses, tests, and simulations; 
parameter matrix uncertainties; sensitivities; failure modes; judgment; and probing questions that should 
be asked throughout the design process. 

1.2.4 Design Process Description 

The main results of this entire activity are developed in this section. First, important aspects of the 
project technical framework are addressed. Then the T-model for technical integration is introduced. In 
this model formal and informal integration are defined. Finally, a symbolic model is developed that 
characterizes technical integration and the design process. This model consists of design function planes 
associated with the vehicle subsystems. These design functions are systems, aerodynamics, trajectory/ 
guidance and navigation (G&N), controls, structures, thermal, propulsion, avionics, materials, manufac- 
turing, and others. In addition to the design function planes, the characterization also includes their associ- 
ated decision gates and engineering tasks. This model is also linked to an existing, detailed discipline 
description via its work breakdown structure (WBS) and NxN matrix from reference 2. While the basic 
characterization has been developed, there are some detailed aspects of the model that are still being 
investigated. 
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1.2.5 Process Improvement 


It is thought that process improvement can be achieved by fine-tuning the present design process 
and implementing revolutionary technologies. While it is planned to investigate these activities in 
follow-on efforts, some ideas associated with process improvements are delineated in this section. Some 
categories associated with fine-tuning are as follows: requirements and criteria, designing for simplicity, 
improved modeling tools, and integration of discipline analyses. The categories associated with revolutionary 
technologies are compartmentalization/reintegration, synthesis and design, and interactive information and 
communications systems. 


1.2.6 Illustrations of Process 

The baseline design process that is characterized in this work was implemented in the Saturn/ 
Apollo and Space Shuttle programs. Examples of the application of this characterization are given in this 
section. An overview of the conceptual design stage is given, and an example is presented of the Space 
Shuttle conceptual design process. 

1.2.7 Distilled Wisdom 

This section pertains to lessons learned and the results of a survey of experienced practitioners. 
During the evolution of the effort presented herein, key ideas were noted. Then upon completion of the 
baseline characterization effort, the process was reviewed to extract important ideas. From these two 
resources, lessons learned were distilled, and they are presented in this section. In addition, a survey of 
experienced practitioners was taken to determine “What is the essence of engineering design based on your 
many years of experience?" Their collective wisdom is also presented in this section. 

The remainder of the report contains conclusions, recommendations, three appendices including a 
glossary, references, and a bibliography. 
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2. DESIGN PROCESS OVERVIEW 


The launch vehicle design process presents a challenge of the highest order. This challenge is 
illustrated in figure 3. It can be seen that after the mission statement is defined, the project must achieve 
the system attributes related to performance, cost, reliability, safety, operability, and schedule via the 
design process. The challenges that the system designer must address are high energy densities, propul- 
sion efficiency, dry mass efficiency, and loss management, along with technology readiness and 
requirements on cost and “-ilities/ As can be seen, the loss management falls into the categories of 
uncertainties and interactions. The design process must rely upon analyses, testing, simulations, and past 
experience to provide insight for trading within and among the various challenges to achieve the best 
design. In addition, this same knowledge base is applied to develop philosophies and methods to support 
subsequent design judgments. The design and associated judgments are eventually assessed after 
development testing and/or in the operations stage and may lead to operational constraints. 


Mission Statement: Insert a specified payload into a specified orbit to the required tolerances, 

within cost, reliability, operability, safety, and schedule requirements. 


Engineering Challenges: 

Design and Management Considerations Project Requirements 


1 High Energy Densities 
» Propulsion Efficiency 
► Dry Weight Efficiency 
► Managing Losses 

- Uncertainties 

• Manufacturing Variables 

• Environmental Variables 

- Interactions 

• Multidisciplinary 

• Interfaces 

• Operations 

►Failure to Meet Technology 
Readiness Level (TRL) Target 
►Cost, Reliability, Operability 


Design To Achieve 



• Performance 
•Cost 

• Reliability 

• Operability 

• Safety 

• Schedule 


Figure 3. STS design — highest order challenge. 


This section provides an overview of the main features of the launch vehicle design process, along 
with associated challenges and connectivity. The details will be included in subsequent sections of the 
report. A thumbnail sketch of the design process sequence is provided to show the ordering of main 
activities of each design stage. 
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2.1 Top-Level Characterization 


The engineering design process has five major areas of emphasis that flow in sequential order: 
(1) Requirements definition, (2) design, (3) build (make or buy), (4) system integration and verification, 
and (5) operations (fig. 4). 



Figure 4. Design process/life-cycle flow. 


Requirements definition specifies what the product is to do and how well it is to do it. It also 
specifies constraints, philosophy, and criteria (e.g., margins, etc.). Therefore, the design process starts with 
the mission statement and requirements. These are defined in terms of the requirements of the orbital 
characteristics (orbit inclination, altitude, etc.) and the payload to be delivered. In addition to the mission 
requirements, other requirements and constraints are also levied. These include cost (design, development, 
testing, and evaluation (DDT&E); operations; life cycle), reliability, development time, etc. NASA has 
program requirements such as design reviews and verification requirements that are contractually levied. 
Many times additional requirements are provided as constraints which may include such things as geometry, 
payload size, and environmental impacts. In conjunction with these mission and programmatic requirements, 
most design and discipline functions have legal criteria that must be met by the design. Finally, requirements 
evolve as the design progresses. These are called derived requirements and take many forms; for example, 
load relief controls and engine turbopump temperatures cut off or shut down. An STS must be formally 
verified to meet all these requirements and constraints before operation; figure 4 illustrates the top-level 
flow down of the process ending with a verified system at the flight readiness review (FRR), thus providing 
an operational system. The process works through system, design, and discipline functions, technical working 
groups, technical interchange meetings, boards, etc., which enhance technical integration and 
communications, thus enabling the design. 
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In order for the design process to work efficiently and take advantage of the state of the art (SOA) 
knowledge base, the STS must be compartmentalized into workable units after the mission and programmatic 
requirements are defined. The SOA information exists in three general areas: (1) Industrial specialization, 
(2) Governmental specialization, and (3)Academic specialization. Figure 5 shows the influence of aerospace 
infrastructure and specialization on design. The capabilities and knowledge bases of these three areas 
constitute the SOA which is captured by standards, monographs, technologies, manufacturing processes, 
etc., shown in the center block of the figure. These become the basis for the design process. The design 
activities consist of (1) compartmentalization of the hardware and tasks into workable units, (2) synthesis 
(concept identification), and (3) analysis and assessment of the synthesized concept. There is a major 
iteration loop between the synthesis activity and the analysis and assessment activity. The results of the 
design activities produce the design specifications. The heart of this approach of compartmentalization is 
the SOA knowledge and specialized processes that have been developed. Design can thus start with SOA 
capabilities that have already been developed. For example, the characteristics of various airfoil shapes 
have been investigated and demonstrated. The designer can choose the one that best fits the product concept 
under design. As another example, joints are a major design problem. Industry and academia have 
standardized various joint concepts and analysis techniques. All these standards, data bases, and processes 
are used for the initial synthesis process. The analysis and assessment function then fine-tunes and optimizes 
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and, thus, resynthesizes the product. (The iteration loop on the figure.) This approach of taking advantage 
of the three specializations, if used properly, can result in a higher quality product at lower cost. 
Compartmentalization by industrial specialization takes advantage of existing industrial expertise and 
infrastructure, thus cutting cost and increasing quality. Government and academia compartmentalization is 
along discipline lines as taught in universities and practiced in Government research labs. Most of the 
complex theories and the corresponding computer codes have evolved along these discipline lines. Discipline 
compartmentalization provides for indepth technical penetration and more efficient analysis efforts. 
Discipline codes are available, including computer aided design (CAD)/computer aided manufactuerers 
(CAM), structural codes, computational fluid dynamics (CFD), thermal codes, as well as many others. 
Government also has many specialized facilities for testing and massive computing, etc., not available in 
industry. Wind tunnels and rocket engine test stands are examples. The three areas of specialization produce 
synergistic technologies critical to the design of future systems. 

The compartmentalization process starts with the definition of the top-level systems that comprise 
the STS overall system, as delineated in figure 6. These are based on specilized capabilities of Government 
and industry. Typically, the first level of compartmentalization is composed of the following. 

• Launch vehicle (design and build) 

• Payload interfaces (accommodations) 

• Operations systems (hardware and software required for assembly, mission operations, and 
refurbishment). 

Depending on the complexity of the STS and the industrial specialization, these systems can be 
defined differently; however, the compartmentalization process is essentially the same. As will be 
discussed later, each of these systems has its own design, manufacturing, and verification processes. 



Figure 6. Top-level compartmentalization of design process. 
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The next step in the process is the allocation and levying of requirements. At this level of compart - 
mentalization, the requirements are apportioned to the three systems. For example, top-level management 
decides what proportion of the STS budget is allocated to each of these. 

Several techniques are available for enhancing requirement allocation to the STS systems and 
subsystems. Quality function deployment (QFD) is the most accepted approach for accomplishing this 
task. It starts with the customer’s wants and translates them into designable attributes of the system. It 
weights the importance of each, providing an indication of priority. The QFD process is described in detail 
in many of the listings in the bibliography; therefore, no further discussion here is warranted. QFD is a 
useful tool to aid the allocation process; however, allocation typically must draw on the judgment and 
experience base of the leader and others involved. 

After the allocations are completed, there are interactions/interfaces between the various systems 
that must be determined and traded in order to achieve overall balance. The vehicle affects the launch pad; 
the launch pad affects other facilities. The same is true of the payloads, etc. These couplings are generally 
weak and can mainly be treated with allocations via interface control documents (ICD’s), etc.; however, 
they must be engineered and balanced to achieve some level of optimization. 

The compartmentalization of the hardware/software systems continues down the tree, with the 
launch vehicle being compartmentalized into subsystems, then into a hierarchy of sub-subsystems, and so 
on into smaller entities, as indicated on the left side of figure 7. Each of the entities on the tree is a 
hardware/software item that must be designed. For purposes of this discussion, we will generically call the 
hardware/software item a subsystem. 

The process of designing each subsystem entails a second type of compartmentalization, as 
indicated on the middle portion of figure 7. This second type of compartmentalization divides the 
subsystem design process into a set of design functions. These design functions are represented by a 
“stack” of design function planes. The specific design functions needed will vary from subsystem to 
subsystem, but typically include the design functions of structures, propulsion, thermal, avionics, 
manufacturing, etc. The products of the design functions are the specifications for their portions of the 
subsystem design. The top plane in the stack is the “system” plane that integrates the other design functions 
into an integrated design (specification) for the subsystem that corresponds to the stack. 

(Note that each subsystem on the tree has its own design function stack. As we move down the tree 
into smaller subsystems, there will be an associated stack with each subsystem until we arrive at parts that 
can be designed by a single designer, making use of handbooks, etc. At this point, further compartmental- 
ization is not necessary.) 

A third type of compartmentalization occurs on each design function plane, involving discipline 
functions. Disciplines are technical areas of specialty and expertise. They perform analyses, tests, and 
simulations in support of the design functions, and they can be thought of as residing on the design 
function planes. This third compartmentalization is indicated on the right side of figure 7. On each design 
function plane, there is an iterative synthesis/analysis activity that draws on all the pertinent disciplines to 
arrive at a design (specification) whose attributes meet its allocated requirements. 
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Hardware/Software Disciplines Functions 

Subsystems Design Functions (Example Disciplines Supporting 

(Example Partial Subsystem Tree) (Example Launch Vehicle System) Structures Design Function) 



Figure 7. Categories of compartmentalization of design process 











Thus, there are three types of compartmentalization — subsystem, design function, and discipline 
function. Each compartmentalization in turn requires reintegration to constitute the complete system 
design. Figure 9 illustrates the three interconnected types of compartmentalization (proceeding downward 
to the right) and their subsequent reintegration (proceeding upward to the left). Completion of the final 
reintegration then results in the total system design. 

These concepts will be further expanded and explained in section 4. The process of technically 
integrating the compartmentalized parts into a successful design is a primary challenge and constitutes a 
main subject of this report. 

To further address the design and discipline function characterization, consider the design function 
“stack” associated with the launch vehicle system, as shown on the left of figure 8. The design functions 
shown are: 

• System 

• Aerodynamics 

• Trajectory/G&N 

• Control 

• Structures 

• Thermal 

• Propulsion 

• Avionics 

• Materials 

• Manufacturing 

• Others 

The structures design function plane is expanded on the right side of the figure as an example of the 
plane content. Also, there is an additional expansion below to show the decision gates that reside on the 
plane. Each plane is a flow diagram which shows top-level activities, beginning with requirements and 
architecture allotted to that design function, then compartmentalizing and reintegrating the discipline 
functions necessary to execute the iterative synthesis/analysis activity to converge on a design specifica- 
tion that meets the requirements. As the design matures through the iterative process, its attributes are 
assessed and compared with the requirements. Attributes are the numerous measures of “goodness” of the 
design in categories of performance, cost, reliability, safety, operability, etc., and are related one-for-one 
with requirements. The comparisons of these numerous attributes with the requirements are represented on 
the decision gate diagram where satisfying all gates means satisfying the summary decision gate on the 
design function plane. 

The top plane of the stack of design function planes is the system plane. It provides the compart- 
mentalization, allocation, and reintegration for the other planes. Its product then is the design specification 
for the subsystem entity on the tree for which the stack corresponds. A major feature of the process repre- 
sented by the stack is the information flow that must occur among the planes. Critical formal feedback 
between the design function planes and the system plane is shown, as well as informal feedback between 
and within the planes. The rectangular vertical conduits with arrows pointing downward represent the 


13 



Figure 8. Illustration of design function stack with structures plane example. 


flowdown of requirement allocations, architecture, and approach. The vertical column with arrows point- 
ing upward represents the upward flow of the design attributes from the design function plane to the 
system plane. These conduits represent formal integration. The circular conduit with arrows pointing both 
upward and downward represents informal integration among the design function planes. Informal integra- 
tion also occurs on the design function plane within and among the various disciplines. 

The large amount of information flow throughout the process will be further characterized in 
section 4, using information flow matrices. Two types of matrices will be used: an interface information 
matrix (designated Ixl matrix) to address information flow among the subsystems on the tree, and an NxN 
matrix to address information flow among design functions and disciplines. Material related to the 
information flow in the launch vehicle design/analysis process has been developed by MSFC 2 that 
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Example Discipline Functions 

(Perform Analyses, Tests, and Simulations) 

• System 

• Structures (Example Expanded Below*) 

• Aerodynamics 

• Control 

• G&N 

• Trajectory and Flight Mechanics 

• Materials 

• Manufacturing 

• Testing 

• Simulation 

• Mission Analysis 

• Propulsion 

• Thermal 

• Life Support 

• Categories of Discipline Tasks: 

• Structures 

- Dynamics 

- Stress 

- Durability 

- Stability 

- Vibroacoustics 



Figure 9. Design process compartmentalization and reintegration. 


addresses discipline inputs and outputs, tasks, and products of the design process. This includes the NxN 
matrix mentioned above, discipline flow charts, and task definitions. These details are integrated into the 
process description given in this document. 


Example Design Functions 

(Develop Specifications for 
Hardware and Software) 

• System 

• Aerodynamics Design 

• Trajectory 

• GN&C 

• Structures 

• Thermal Protection System (TPS) 
and Thermal Control Systems (TCS) 

• Propulsion 

• Avionics 

• Materials 

• Manufacturing 

• Facilities and Ground Support 
Equipment (GSE) 

• Operations Software 

• Other Systems; e.g., 

- Pyrotechnics 

- Recovery Subsystem 

- Life Support 

- Etc. 
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Figure 10 is another way of illustrating the complexity of design/discipline interactions, data 
exchanges, and balancing. This figure illustrates some (but not all) aspects of design interactions. Expand- 
ing it to include all aspects would cloud the visualization process. Another example of visualization of 
design interactions is shown in figure 1 1 . This figure includes some details of the internal process flow for 
the structural subsystem. Technical integration is a complex process, as this top-level discussion shows. 
This document will probe further into its definition. 



In summary, the process starts with requirements definition, moves to top-level system studies, 
then to the compartmentalization of the overall system by comprising systems by subsystems, etc. Their 
design is accomplished by the design functions, supported by the discipline functions. Design is followed 
by manufacturing/assembly/checkout. The design as built must be verified to meet the requirements through 
analysis, test, and simulation. Operational procedures are derived from the design and verification process. 
A schematic of the interaction of the design functions and discipline functions is depicted in figure 12. The 
process (integration) is very complex and requires focused communication, both formal and informal. 
Detailed discussion of these aspects is given in section 4. 
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Figure 12. Design process flow. 







2.2 Engineering the System 


The design process must be focused on achieving the best total system design to meet the require- 
ments. The leader is responsible for managing the design process, for engineering the system. His respon- 
sibilities are reflected on the top-level system design function plane, and entail wide-ranging judgment and 
constant communication with members of the design team. Engineering the system involves the following 
essential functions. 

Essential Functions of Engineering the System 

• Obtaining and Assessing Requirements 

• Synthesizing Concepts and Designs 

• Compartmentalization 

• Technical Integration 

• Risk Management, including Technology Development Risks 

• Trading and Balancing 

• Downselecting Concepts and Designs 

• Manufacturing, Integrating, and Verifying the Design 

• Developing the Flight Operations Rules and Constraints. 

There are numerous tools used to accomplish these essential functions. In addition to generic 
management tools, there are tools that are more specific to the design process. Categories of such tools 
include the following. 

Typical Tool Categories 

• Requirements generation tools, such as QFD 

• Synthesis-aiding tools, such as TRIZ 

• Sizing programs 

• Computer-aided design programs 

• Design optimization tools 

• Engineering analysis 

• Manufacturing process simulation tools 

• Engineering test 

• Sensitivity analysis 

• Cost analysis 

• Decision tools for trade studies 

• Risk management tools, including FMEA, fault trees, and risk/consequence analysis 

• Classical systems engineering tools, including requirements flowdown, WBS, configuration 
management, and verification plan 

• Design reviews 

• Integrated Information and Communication System. 
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2.3 Thumbnail Sketch of Process 


This section provides an overview of the process sequence, divided by design stages. 

2.3.1. Conceptual Design 

2.3.1. 1 Conceptual Design Definition. After the mission statement, requirements, and constraints 
are defined and understood, feasible alternative top-level system concepts are defined and their attributes 
determined via trade and sensitivity studies. Along with each concept there are supporting studies related to 
risk, cost, reliability, schedule, safety, operability, refined requirements, facility/GSE concepts, TRL, project 
plans and other documents, etc. Selection criteria are also developed to evaluate the alternative concepts. 
At the completion of conceptual design, there is a review called the system definition review (SDR). 

2.3. 1.2 Activities. Conceptual design follows a process with the following steps: 

a. Identify the basic mission requirements (mission definition, pounds of payload to orbit, cost, 
schedule, etc.) 

b. At the top level, define potential concepts to meet requirements (includes overall architecture, 
staging, reusability, and broad definitions of propulsion system(s), structural systems, 
avionics, and thermal systems). 

c. Define evaluation metrics. 

d. Perform top-level sizing and analysis of the concepts. 

(1) Preliminary estimates of geometry, mass, environments, and propulsion characteristics 

(2) Trajectory and performance definition 

(3) Induced environment definition 

(4) Top-level sensitivity study (example: dry weight versus dry weight margin) 

(5) Margin determination necessary to envelope uncertainties 

(6) Determination of performance, cost, and other attributes 

(7) Risk assessment and technology development needs 

(8) Trade and balance among alternatives to improve attributes and risks 

e. Develop selection criteria and select top contenders. 
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f. Modify the contending concepts based on evaluation data. 

g. Repeat the above process with more in-depth evaluation. 

h. Downselect to remaining candidate concepts. 

i. Modify the remaining candidate concepts based on evaluation; add new ones (if data indicate). 

j. Modify requirements (if data indicate). 

k. Continue to repeat the above process until clear, leading concepts emerge. 

l. Define the leading concepts with general configuration definition, sensitivity data, and induced 
environments. 

2.3.1.3 Products of Conceptual Design. The products of conceptual design are a reduced set of 
feasible alternative concepts that have attributes which satisfy the mission statement, requirements, and 
constraints with acceptable margins and risk. In addition, there are additional supporting data as mentioned 
above in the definition. In some situations there may be only one concept selected. 

The concept selection quantification leading to selection therefore requires a small cadre of inven- 
tive, sound engineering specialists who carry out the tasks. The tasks in the early part of conceptual design 
can be integrated together into one program for overall sizing; however, the operational requirements and 
output of this program must be assessed by the respective disciplines for technical soundness. The tasks for 
the subsequent program stages, however, have increasing levels of penetration, detail, and scope as the 
program matures and is verified. 

2.3.2. Preliminary and Detail Design 

Preliminary and detail design follow the same general approach; i.e., the steps; however, the depth 
of penetration and the results differ significantly. 

2.3.2.1 Preliminary Design Definition. The purpose of preliminary design is to determine which 
of the selected concepts from the conceptual design stage is the best and to provide greater assurance that 
the concept is capable of meeting requirements. To achieve these results, the fidelity of the architecture is 
increased and refined; in addition, the significant subsystems and their requirements are defined. The depth 
of penetration of trade and sensitivity studies is increased through analyses, tests, and simulations. Then 
the requirements, risk, cost, reliability, safety, operability, schedule, and TRL are refined and reassessed. 
Interfaces, interactions, pertinent tests, top-level verification plans, and preliminary facility and GSE 
requirements/concepts are defined and the fidelity of the project plans and documents is updated. Prelimi- 
nary design can occur in iterations as concepts are downselected after each iteration until the best concept 
remains. This concept then goes to detail design. In the situation where only one concept goes to prelimi- 
nary design from conceptual design, the above procedure is still utilized but for a single concept. At the 
completion of preliminary design, there is a review called the preliminary design review (PDR). 
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23 . 2.2 Detail Design Definition. The purpose of detail design is to provide drawings and specifi- 
cations for all the hardware and software of the fully analyzed, tested, and simulated STS that can be 
manufactured and operated within cost and flown with an acceptable risk. The performance, cost, 
reliability, safety, operability, schedule, and technology readiness attributes of this system must satisfy the 
mission statement, requirements, and constraints. At the completion of detail design, there is a review 
called the critical design review (CDR). 

2.3.2.3 Activities. Preliminary and detail design follow the same general approach (steps). 
Preliminary design operates at less depth because the analysis and test data have not matured. Detail design 
is in-depth and finalizes all the design trades and the configuration for production. The steps are in general 
the following: 

a. Using the database and the concept selected, apportion the design task by first — 

(1) Delineating the major subsystems, elements, components, etc. 

(2) Allocating requirements, constraints, etc., to these entities and their associated 
design functions. 

b. Start the design function and discipline process for each major subsystem. 

(1) Define in more detail the data base required for the discipline task. Data bases include 
mass properties, aerodynamics, thermal, materials properties, etc. 

(Note: Steps b(2) through b(7) are examples pertaining to structure design.) 

(2) Run the trajectory/performance analysis. Provide data to other disciplines. 

(3) Using the baseline trajectory, conduct the control analysis determining the control logic, 
control requirements, and responses. 

(4) Conduct the loads analysis definition using the control results, determining the induced 
structural environments. 

(5) Determine the thermal environments, loads, etc. 

(6) Perform stress analysis and its subsets of strength, stability, deflections, and durability. 
Durability also includes fracture and fatigue. 

(7) Determine sensitivities and margins. 

(8) Perform trade studies among alternatives. 

(9) Assess risks and technology development plan. 

(10) Reintegrate design functions and subsystems at each level. 


21 


(1 1) Perform risk assessments and trade studies, and balance design at each integrated level. 

c. Modify the design based on the results. 

d. Repeat the process in more depth. 

The above sequence overviews trajectory/performance design, some controls design, and structural 
design. There are concurrent parallel design activities for other subsystems and design functions, such as: 

• Thermal protection and thermal control 

• Manufacturing 

• Avionics 

• Propulsion 

• Other systems such as pyrotechnics, recovery, etc. 

These subsystems and design functions have their own design sequence and also interact with the 
design process of other subsystems. 

Two major activities that permeate the design process are (1) trading among design alternatives to 
balance the competing aspects of the design, and (2) assessing and managing risks. Trades range in com- 
plexity fj;om straightforward judgment decisions to detailed trade studies that drive out the differences in 
design alternatives. Because of the strongly coupled nature of launch vehicles, trade studies are usually 
numerous and constitute a significant part of the design process. A balance must be achieved among the 
cost, performance, operability, etc., of the design. Achieving the best design also requires balancing among 
the subsystems, design functions, and technical disciplines. 

Technical, cost, and schedule risks must be actively managed throughout development. Active risk 
assessment is an essential element of the design process. Failure mode analyses and risk/consequence 
assessments are done for each design alternative. A technology assessment for each design alternative 
identifies technology development required, along with the risk associated with maturing the technologies 
to an acceptable level. 

2.3.2.4 Products of Preliminary Design. The major product of preliminary design is a single 
concept that has attributes that satisfy the mission statement, requirements, and constraints with acceptable 
margins and risk. The margins and risks at the completion of preliminary design should be reduced from 
those at the completion of conceptual design. The concept at the completion of preliminary design is the 
baseline for detail design. In addition, all system support, manufacturing, test, and operations requirements 
are also defined. 

2.3.2.5 Products of Detail Design. The products of detail design are engineering descriptions of 
the hardware and software pertaining to STS. These descriptions are drawings, specifications, plans, etc. 
The attributes associated with the system must satisfy the mission statement, requirements, and constraints 
with acceptable margins and risk. At this point the margins and risks should be at a minimum. Additional 
products include plans for final development, manufacturing, verification, and operations. 
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2.3.3 Successive Refinement. 


During the design process, there are various stages. The process has been divided into stages in 
order to provide discipline and order while demonstrating evolving technical maturity with cost and 
schedule adherence. The idea of successive refinement adds emphasis by focusing attention on 
convergence to a concept (see fig. 13 and references 3 and 4). When the design process is first initiated, 
there is considerable uncertainty (i.e., risk) associated with technical, schedule, and cost feasibility. In 
addition, the knowledge base can be very limited. As the project proceeds, concepts are studied and assessed 
in regard to satisfying all the requirements and constraints. These studies are iterative, and on each cycle 
the penetration is deeper and deeper. The results provide information about the concept options and then 
decisions are made that eliminate certain options. As the design continues, the knowledge base is refined 
and increased iteratively while the uncertainty is decreased. Eventually, through this successive refinement 
of knowledge, decisions can be made to downselect to the best concept. There have been projects where 
the downselect was achieved in the conceptual design stage, and there are others where it was late in the 
preliminary design stage. There are other government agencies where protoflight hardware is developed, 
and the downselect is determined by comparison of the actual function, cost, and production schedule. 


Front-end Design Work 


i 


Product Design 
Specifications (PDS} 


I 


Apply Controlled 
Convergence (CC) 

Apply Concept 
Generation (CG) 
CC 


Concept Generation 



(See Reference 3) 


Physical realization of a system results from a 
succession of decisions among alternative concepts. 

Decisions at every step require that new information 
be developed to mature the concepts. 

As concepts are continuously refined and uncertainty 
is reduced, choices among concepts can be made with 
confidence. 


Concept selection consists of the defining and 
understanding alternative concepts and implementing 
decisions that lead to downselecting one concept. 



Iterate/penetrate Until the Degree of Uncertainty and Concept 
Discriminators Warrant Moving to Next Design Phase 


Figure 13. Successive refinement. 
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3. ESSENTIALS 


Before presenting the methodology in detail, it is necessary to understand some essentials that are 
applicable to each design function and program stage. These considerations sometimes are subtle and 
implicit in the process, but they are of such importance that we have called them “essentials.” 

3.1 Basis of Good Engineering 

The process described is logical and depends on methodology, not dogma. Guidelines, procedures, 
and criteria augment the process but can never replace the human mind, the human judgment. In the end it 
is the individual or collective judgment that results in key design decisions. The methodology is based on 
the scientific method geared to question the validity of the data and logic. Furthermore, the basis of good 
engineering can be characterized as (1) sound physical principles and logic (design must be based on the 
physics of the problem), (2) depth of engineering experience as a basis for judgment, and (3) communica- 
tions, communications, communications. 


3.2 Constraints 

The constraints must be defined and evaluated, because they greatly alter a design. Therefore, it is 
imperative that their effects be understood and quantified before acceptance. Most constraints are initially 
based on historical data. For example, the maximum dynamic pressure for the Space Shuttle is constrained 
to 650 psf nominal and 815 psf dispersed. Manned flight levies an acceleration constraint of 3.15 G’s 
maximum. As the studies/design progress, constraints evolve, and changes are made based on the effects of 
sensitivities and trades. Cost and schedule constraints are much more difficult to implement, because they 
have both programmatic and technical interactions that occur in a variety of ways. 

3.3 Derived Requirements 

During the design process additional requirements evolve. These derived requirements are neces- 
sary to balance the system and are determined through basic trade studies where top-level requirements 
must be met. These are usually the basis of how the system is flown and/or how it is made to work. 
Examples of derived requirements are load-relief control, monthly mean-wind biasing, day-of-launch 
Moad updates, ground wind operational constraints, etc. Typically, derived requirements are evolved and 
implemented; however, they in general introduce additional failure modes that must be identified and 
assessed. 


3.4 Formal Design Criteria 

In the design process, the design must meet numerous requirements and constraints. Among these 
are the formalized design criteria applicable to all NASA projects. These are in the form of formal docu- 
ments, and they exist at both NASA Headquarters and at the various Centers. The Center-levied criteria 
and requirements can be tailored for individual projects; however, the NASA Headquarters criteria must 
not be violated in intent. The discipline specialists develop most of these Center-associated criteria even 
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though they may be listed in the systems requirements. One of the main activities of the system design 
function is to determine what criteria will be imposed on the design. It is very important for the system 
design function and the project to tailor the criteria for their specific needs. First, these requirements/ 
criteria delineate the various design stages and the levels of project maturity required for each. The main 
discipline criteria apply at each stage but recognize the level of project maturity. Also at the system levels 
are the verification requirements, including the requirements for the verification matrix, documentation, 
etc. Each individual discipline provides input to verification requirements; however, the individual design 
functions are responsible for their development and implementation. 

Many specialized discipline criteria exist for use by the design functions. Structures have formal 
criteria for strength, endurance, stability, etc. Safety factors are defined as well as detailed approaches for 
verification (test and analysis), model correlation, model update, uncertainty factors as a function of pro- 
gram maturity, etc. These criteria become very formal gates in the structures design function and must be 
met or waivers developed. For example, loads analysis initially uses a 1.5 factor on loads; as the project 
matures, this factor may drop to 1.25. At the completion of the modal survey test and when the dynamic 
model correlation is finalized, the factor becomes 1 . The strength and fracture disciplines assessment 
requires an indentured parts list to ensure that all parts have been analyzed. From this list a fracture critical 
parts list is developed which requires fracture analysis and nondestructive evaluation (NDE). Proof pres- 
sure testing of various parts is specified along with the proof factor. Materials have a comparable set of 
criteria, from material usage, to processing, to characterization. The control discipline has a less rigid set of 
criteria. It depends more upon judgment using established guidelines such as phase and gain margins, as 
well as response characteristics. The thermal discipline mainly depends on conservatism in the analysis 
and design process without having specific margins defined. In the aerodynamic discipline, stability 
margins exist for flutter, etc., and are spelled out in the NASA documents. There is an old but very good set 
of NASA design monographs that can be applied as guidelines for design. Most industries have design 
manuals spelling out procedures as well as criteria. There are many good books also on the subject. Pugh in 
Total Design 1 * 3 says that development of these criteria for each project by the various disciplines is very 
critical to development of successful products and can be considered the mantle which envelops the project. 
This document is focused on the design process and not the detailed design criteria; however, they are very 
important. 


3.5 Categories of Modeling/ Activities 

Throughout the vehicle design and operations processes, the vehicle performance and physical 
attributes are characterized by descriptions or models of varying fidelity. At today’s state of the art, it is not 
possible to have one single model that describes in full fidelity all of the vehicle constituents and interac- 
tions. Likewise, it is not possible to address total vehicle design as a single comprehensive synthesis/ 
analysis activity. In the category of vehicle performance and physical attributes, there are three parallel 
sets of descriptions and activities: 

1. A generalized description of the vehicle that is evolved through synthesis/analysis activities 

directed toward overall vehicle performance. This category encompasses trajectory/ 

performance, load cycles, and overall vehicle design for ascent and return. 


25 


2. Discipline-specific descriptions that are developed from discipline analyses, tests, and simula- 
tions. This set of models feeds its information to the other two sets. The descriptions increase 
in fidelity as the design matures and additional analyses and tests are performed. 

3. Specialized descriptions and synthesis/analysis activities that are applicable to specific 
interactive aspects of the vehicle, such as flutter, pogo, rendezvous and docking, etc. These 
issues are addressed separately from the generalized description with their design consequences 
being fed into the generalized description. (The generalized description should initially allow 
“headroom” for the accommodation of the specialized interactive aspects.) 

The generalized description is the “backbone” of the design. It increases in fidelity throughout the 
design process. Upon entering the operations stage, a less-detailed description is extracted from the 
generalized description to serve as a basis for executing operational constraints. 

In addition, there is a second category of models that must also be developed. These models are 
other than those associated with vehicle performance and physical attributes. They are in a general 
category related to constraints but could include some ancillary requirements. These models are associated 
with risk (technical, cost, and schedule), cost, reliability, safety, operations, and other associated -ilities, 
and they provide the means to assess and manage this category of associated design activities. 

3.6 Analyses, Test, and Simulation 

To design a successful launch vehicle, the design and discipline functions must produce correct and 
effective technical results. While technical integration is emphasized herein, it can be no better than the 
information flowing within it. Consequently, correct and effective discipline results are essential founda- 
tions of the design process. The discipline functions accomplish their tasks using analysis, test, and simu- 
lations. For example, the analysis starts by formulating describing equations or a mathematical description 
of the plant. This model can never exactly describe the response of the system nor of the natural and 
induced environments. Therefore, the model is an approximation of the plant and the environments. In 
other words, the analysis uses a model based on a set of assumptions derived from experience and what is 
known about the system. These assumptions must be constantly challenged and revised. Many errors occur 
because assumptions are considered sacred and are not challenged. The evolving database is the anchor for 
the modeling process. Engineering judgment in drawing from the database and applying assumptions to 
the models is based on experience. These models should be validated by benchmarking methods and 
verified in developmental testing. 

The testing process has similar limitations. The actual flight environment cannot be duplicated. In 
order to reduce cost, etc., only the essentials of the hardware are tested. For example, in dynamic testing 
many of the parts are mass simulated. Programmatic and technical constraints dictate these approxima- 
tions. As in analysis, engineering judgment based on experience and the evolving databases is the basis for 
assumptions regarding what hardware is to be tested and what critical combined environments are to be 
applied. Simulations are subject to the same considerations as analysis and test. 

In summary, a successful design depends upon the discipline functions understanding physical 
principles, applying proper assumptions, and producing accurate results. 
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3.7 Parameter Matrix and Uncertainties 


Each design and discipline function must define and quantify all parameters and their uncertainties. 
Initially, they are based on engineering judgment. As tests are run and analyses refined, the bands of uncer- 
tainty are reduced. In general these uncertainties are defined with some statistical measure, e.g. 3-sigma, 
level relative to a nominal or mean. When possible, a distribution is defined. Also, procedures for proper 
application of these uncertainties are developed. The discipline specialists are the only ones knowledgeable 
enough to develop this data. Management’s job is to question the assumptions and assure that unneeded 
conservatism is avoided. In the early design stages of the Space Shuttle, the Ascent Flight Integration Work- 
ing Group (AFSIG) spent approximately 4 months developing the parameter uncertainties matrix for each 
flight phase along with the analysis/test philosophy and procedures. Although prior program history can 
serve as guidelines, the process must be repeated for each new project. Future trends are toward more 
probabilistic methods of design. 


3.8 Sensitivities 

The response of the system and its sensitivities must be determined. This can be accomplished 
through analyses, simulations, or tests; however, it is usually accomplished through analyses. The higher 
the sensitivity, the tougher the design problem. 

3.9 Failure Modes 

Failure modes must be identified. Classically, there are two ways to identify failure modes. In the 
first, failure modes are defined and assessed by discipline and design functions relative to criteria, for 
instance various design limits, etc. On the structures plane designers and stress analysts 
routinely assess and eliminate or mitigate failure modes. For example, structural failure modes are 
assessed using specified factors of safety for strength, stability, endurance, and others that are specific to 
the structures design function. The assessment consists of comparing the structural capability with respect 
to the design limit to determine the structural margin. In the second, potential failure modes are defined by 
a team of discipline, design, and system specialists, but from the systems perspective. This activity is 
orchestrated by the system plane. The failure modes are usually put into some formal tree or cascading 
logic diagram. The uncertainty/sensitivity data are used to assess the failure modes and the trade study 
results. This assessment is made using engineering judgment augmented with risk versus 
consequence logic which relates to quantification and impact using uncertainties, sensitivities, risks, and 
consequences. This process utilizes failure modes and effects analysis (FMEA), critical items list (CIL), 
and hazards analysis. 

In the final analysis this is a balancing act between wanted and unwanted characteristics. Gordon in 
Structures or Why Things Don’t Fall Down 5 says: “All structures will be broken or destroyed in the end. 
Just as all people will die in the end. It is the purpose of medicine and engineering to postpone these 
occurrences for a decent interval: the question is: What is to be regarded as a decent interval?” Pye in The 
Nature of Design 6 discusses the source of problems and their compromises. He talks about the source of 
problems dealing with the manifestation and transfer of energy. He says: “Any of these forms of energy is 
capable of producing changes, changes in things; more exactly, redistribution of matter. Now whenever a 
change is made by the passage of energy and a result is left, this event takes place in a group of things. 
Things are always together. They do not exist separately and they cannot act separately. When you put 


energy into a system, you can never choose what kind of changes shall take place and what results shall 
remain. All you can do, and that only within limits, is to regulate the amounts of the various changes. This 
you do by design.” He talks about the compromises in the “design for failures.” “The requirements for 
design conflict and cannot be reconciled. All design for devices are to some degree failures.” The designer 
or his client has to choose to what degree and where there shall be failure. It is important in this process that 
engineers have a network of specialists that can be called upon for understanding these problems. 

3.10 Judgments 

Good engineering judgment is a critical essential to the design process. Judgment is based on 
insights gained through experience. Whenever possible it should be backed up with either a quantitative or 
qualitative assessment. Many times it is hard to quantify the decision; however, in these cases, relative 
comparisons can be used to support the decision. 

Judgment comes into play in many aspects of the design process. First, the compartmentalization 
process of deciding which components can be lumped into a subsystem or sub-subsystem is a judgment 
based upon the coupling and complexity of the components and industrial specialization. Second, the 
balance between performance and programmatic issues (costs, schedule, risk, etc.) are generally made 
using judgment in the presence of available data. Third, many desirable technical refinements must be 
balanced against priorities, risks, etc. Although some parts of the decision can be quantified, most become 
a judgment. Fourth, test options, test configurations, and test conditions are also judgment calls. 

Finally, technical judgments are targeted to be within some acceptable risk that ensures eventual 
flight success. In fact, detail design and operations eventually become a process of managing risk since 
STS systems are so finely tuned. 


3.11 Probing Questions 

The question always arises, “How does management ensure the job is done correctly, and when do 
they know that it is completed?” In general this is accomplished through asking a series of questions. 
Typical questions are — 

• Does the design meet requirements with adequate margins considering uncertainties and 
sensitivities? 

• Have all discipline analyses/tests/simulations been completed to the appropriate fidelity? 

• Has adequate interdisciplinary technical integration been done? 

• Have issues and concerns been adequately identified and dispositioned? 

These questions lead to the general question, “How do I determine adequacy?” The answer is 
usually a judgment for which the following questions offer assistance: 

(Method) 
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• Define and explain ground rules and assumptions. 

• What was your analysis method? How was it benchmarked? 

• What comparative analyses, simulations, and tests have been done? 


• What affects your system? What is it sensitive to? Have the interactions been considered? 

• What does your system affect? Have you worked these interfaces? 

• What concerns do you have with the design (or analysis/test process)? 

(Results) 


• What trends/pattems are present? 

• Are they consistent? Explainable? 

• What are the margins and the basis for the margins? 

• Can the observed characteristics be explained using a simple analogy? Using a free body diagram? 
How does one explain the load paths? 

• Does it pass “the physics of the problem” check? 

(Specialist) 

• What is the engineer’s understanding and feeling of the uncertainties? 

• What is the specialist’s track record? 

• What is your specialist comfort level? 


JR. Thompson told Bob Ryan the following story that gives insight into how decisions are made. 
At the time, J.R. Thompson was MSFC’s Chief Engineer following his tenure as the Space Shuttle Main 
Engine (SSME) Project Manager. He said that when he and Bob Ryan were working together to solve some 
SSME problems to get the first Shuttle flight off (had slipped at the time more than 1 year), Bob Ryan 
would talk to him about dynamic issues that needed to be resolved through redesign. He said, “Those 
dynamic problems scared the hell out of me.” He went on to talk about the only way he could honor the 
political viability was to delay the redesign, handling the safety issue by changing parts after each flight, 
imposing stringent inspections and strict process control, thus launching the first six Shuttle flights 
successfully. At the same time he supported efforts which downstream resolved the issues. He asked Bob 
Ryan to write a paper on the dynamic issues and their resolution as lessons learned, because he said, “Their 
resolution was one of the keys to Shuttle’s success, and he felt it was a meritorious accomplishment. He 
understood that the approach he took was more costly but politically necessary. The approach effectively 
managed risks versus consequences. Engineering in general involves not only technical factors but also 
managing risks driven by political factors. 

Bob Ryan asked Bob Thompson, Level II Shuttle Program Manager at Johnson Space Center (JSC), 
how he made decisions. Bob Thompson was a master at listening to technical presentations in detail and 
asking penetrating questions. His answer, paraphrased as best Bob Ryan can remember, “I must effectively 
listen to each and understand what is said; however, I try to gauge the different technical people in terms of 
their integrity and their conservatism. If the decision I think is correct is agreed to by the specialists that I 
have confidence in and who are conservative, the decision is easy. If they don’t agree, I consider what I 
believe to be their level of conservatism versus the level of unconservatism others have, balancing in my 
mind the risks and consequences between the conservative and unconservative; then I make a decision. 
The decision can be somewhere between the differences or can be the unconservative if the risks versus 
consequences are acceptable. In the discussion of the various task examples in the following sections, 
further elaboration of these general points will be presented. 
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4. DESIGN PROCESS CHARACTERIZATION 


The purpose of this section is to describe figuratively the design process workflow, the tasks, and 
the key decision gates currently used in the design process for launch vehicles. The design process descrip- 
tion is a symbolic visualization that characterizes various design functions and their associated enabling 
discipline functions. Included in this characterization is a representation of how significant interaction 
activities are achieved via vertical and horizontal technical integration. The design functions, discipline 
functions, and technical integration are a complex system of multidisciplinary activities. This has been 
studied in order to develop a characterization of a baseline launch vehicle design process which is 
presented in this section. 

An overview of section 4 is now given, as seen in figure 14. This overview figure shows the 
following: Various levels of compartmentalization and reintegration; aerospace specialization; T-model; 
subsystem tree, stack of design function planes; the supporting decision gate diagrams; the Ixl interface 
diagram, NxN activities diagram, and the design process balancing act. For the various design stages, 
compartmentalization and reintegration are generic processes that enable the structure of the design 
process technical integration. The system is compartmentalized into a subsystem tree with an Ixl diagram 
representing interface data flow among the tree elements. The design functions are responsible for hard- 
ware and software products that are supported by analysis, simulation, and testing activities of the 
discipline functions. The flow of technical information is managed through formal (represented by the 
square conduits) and informal (represented by the circular conduits) technical integration. The NxN dia- 
gram illustrates information flow among the design functions and disciplines. The technical information 
(i.e., all of the attributes) flows to the system plane where it is appropriately balanced to the achieve project 
requirements. 

To set the stage for the characterzation, a discussion of project technical framework and a 
“T-model” of technical integration are provided first. Then the design process characterization is presented 
which delineates the launch vehicle design functions with vertical and horizontal integration that is overarched 
with the system design function. Subsequently, each of the design functions is specifically addressed in 
order to show the flowdown of requirements; implementation of philosophies, procedures, and criteria; 
development of parameter matrices with associated uncertainties; specific enabling disciplines and associ- 
ated multidisciplinary horizontal integration; and, eventually, the desired product attributes. In parallel a 
discussion of the decision gates and the tasks associated with each specific design function is presented to 
complete the characterization of the baseline launch vehicle design process. The baseline process is merged 
with the launch vehicle generic information flow description. 2 

This process description is applicable to all the launch vehicle design stages. To demonstrate this 
wide-ranging applicability, it has been applied to the design sequence at a top level. First, it is applied to the 
conceptual design stage, and then it is applied to the preliminary and detailed design stages. 
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4.1 Project Technical Framework 


Technical integration is required to be accomplished in an orderly fashion; therefore, a framework 
is needed to provide an organized and disciplined structure to requirements definition, project workflow, 
WBS, configuration control, systems analyses, trade studies, system verification, reporting, documenta- 
tion, etc. This framework is developed, maintained, and coordinated via the functions of project planning, 
control, and documentation. The activities associated with these functions are accomplished by the 
systems engineering discipline. In reference 6, the systems engineering discipline is delineated in a global 
sense; i.e., the definition is generic and considered by many to be the “classical systems engineering” view. 
In the application of classical systems engineering discipline to the STS design process, it supports the 
activities of the project leader on the system plane. From that view, the systems engineering discipline 
contribution is through the system design function in the same way that stress analysis contributes to the 
structures design function (see sections 4.3.2 and 4.3.6, respectively). 

The primary activities of the systems engineering discipline, as delineated above, are in executing 
the functions of planning, control, and documentation, see references 7, 8, and 9. It should be noted from 
section 4.3.2, that the products of the system design function are validated STS design specifications and 
attributes, balanced design attributes and requirements, and an operations plan. All these are achieved via 
technical integration (see section 4.3), which is orchestrated by the project leader. The project leader needs 
to accomplish the demanding multidisciplinary interaction tasks associated with technical integration in an 
efficient and effective manner. The project framework enables him to orchestrate the design and to balance 
its attributes in an orderly fashion by providing the necessary discipline and structure. While he uses the 
tools and functions of the systems engineering discipline to achieve order in the process, he leads and 
orchestrates the other design functions to achieve balanced design specifications. The tools of the other 
engineering disciplines are implemented interactively among and between the various design planes to 
accomplish the complex multidisciplinary engineering tasks and then their results are integrated and 
balanced by the project leader via technical integration. 

The purpose of this section is to delineate select key aspects associated with the STS design process 
project framework. In this sense, it focuses on specific highlights that are considered typical. They are 
project stages, project main products, technical effort distribution, typical organizations, and roles and 
challenges. For more details related to the STS design process functions of planning, control, and 
documentation (see references 7, 8, and 9). 

4.1.1 Project Stages 

Most projects are subdivided into stages (see fig. 15). It has been demonstrated through various 
projects that this approach is successful. Historically the phases associated with most NASA projects are A, 
B, C, D, and E. In phase A, the major goals are to determine the project objectives along with assessment of 
feasibility. These activities correspond to the conceptual design stage. Additionally, the need for technology is 
assessed, and various concepts are selected for trade studies. In phase B, the focus is on refining the selected 
concepts through trade studies; system analysis and simulations; refined system and support requirements; 
definition of preliminary manufacturing and test requirements; definition of advanced technology and 
advanced developments requirements for focused funding; and assessment of technical, cost, and schedule 
risks. These activities correspond to the preliminary design stage. In phase C, the focus is on completion of 
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detail design of the selected concept; performance of detail systems analysis; and development of final manu- 
facturing, testing, operations, supporting systems and facilities plans. These activities correspond to the detail 
design stage. In phase D, the focus is on development and test of prototype/protoflight hardware; verification, 
validation, and qualification of hardware and software for flight; manufacturing and integration of flight 
hardware; checkout of flight systems; launch operations; and initial flight operations. These activities corre- 
spond to the manufacturing and systems integration/verification stages. In phase E, the focus is on mission 
operations and disposal. This corresponds to the operational stage. 

Throughout the duration of the design process the aforementioned phases of the program are final- 
ized with formal reviews. These reviews represent the project milestones; i.e., project gates, and are shown 
in figure 16. The purpose of these reviews is to focus the progress of the project and verify that the project 
is proceeding as planned. Throughout the design process there are about 12 major reviews; however, there 
are numerous intermediate reviews. The project reviews that must receive major support from the design 
laboratories are as follows: 

• Systems requirements review (SRR) 

• Preliminary Design Review (PDR) 

• Critical Design Review (CDR) 

• Design Certification Review (DCR). 

For all formal reviews that occurred in the past, there was a specific process that was required to be 
followed with clearly specified outputs. The guidelines for these reviews were contained in NASA 
Management Instructions (NMI’s). 

Recently, NASA issued updated procedures and guidelines for the management of systems. 10 It 
defines the requirements that managers must meet in formulating, approving, implementing, and evaluat- 
ing programs and projects. The program phases discussed above (i.e.. A, B, C, D, and E) have been 
replaced with four subprocesses. They are as follows: (1) Formulation, (2) approval, (3) implementation, 
and (4) evaluation. The various design stages delineated in figure 15 must still be accomplished by the 
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leader whether they are called phases or subprocesses. However, the manner that they are accomplished 
must be appropriately tailored for efficiency and effectiveness. The rationale behind the 
management guideline is “faster, better, and cheaper.” The themes are as follows: (1) Tailoring the process, 
(2) end-to-end customer involvement, (3) comprehensive definition and requirements control, (4) risk 
management, (5) missions enabled by technology, (6) technology commercialization, and (7) International 
Standards Organization (ISO) 9000. 
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Figure 16. Project phases. 


4.1.2 Main Project Products 

For each design stage there are certain products that are required. A generic specification of these 
products is given in various NASA documents. These specifications are meant to be guidelines in the sense 
that each project can tailor the products consistent with the specific design stages. However, the projects 
are subject to peer review, and certain products are required and others are expected. It is the responsibility 
of the leader to determine what products are needed to demonstrate that their project is technically sound, 
on schedule, and cost effective. Typical products associated with the various stages are shown in figure 17. 
The products delineated here are meant to be illustrative and are not all inclusive; however, they provide 
some indication of what is needed. In cases where the peer review results in excessive criticisms, referred 
to as review item discrepancies, there is usually a delta review for that stage and additional products can be 
added at that time. This can happen in very complex programs, and the value added is that the peer review 
forces the project to become technically sound, on schedule, and cost effective. Reviews are successful 
when the products are completely integrated through formal and informal communications. The systems 
engineering discipline supports all these activities by organizing and coordinating the various reviews and 
subsequently tracking/documenting results and action items. 
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Figure 17. Project main products. 


4.1.3 Technical Effort Rate Distribution 

A typical technical effort rate distribution is illustrated in figure 18 for the various project stages. It 
should be clear that each specific project will have its own particular distribution. It can be seen that about 
6 percent of the technical effort is allotted to the conceptual design stage and about 20 percent allotted to 
the preliminary design stage. The remainder of the effort goes into detailed design, manufacturing, systems 
integration, and verification. At this time there is some controversy regarding the amount of effort that 
should be allotted to the conceptual design stage. There is a trend in the engineering community to put 
more effort into the conceptual design stage, especially in situations where the design concept is revolu- 
tionary. At least 80 percent of the life-cycle costs are determined by decisions made during the conceptual 
design stage (see section 4.4. 1.1). 


4.1.4 Typical Organizations 

Engineering projects can be organized as shown in figure 19. In this figure is shown the leader and 
supporting subsystem teams. While this structure can be considered typical of a project type organization, 
it is noted that the design process as characterized herein does not depend upon any organizational struc- 
ture. The elements of the design process must be executed regardless of the organizational structure. In the 
past, several different types of structures have been implemented to achieve the project goals. Figure 20 
from reference 11, but slightly modified, shows four basic types of organizations that have been 
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Figure 18. Project total technical effort rate distribution. 



Figure 19. Typical project management organization. 
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implemented in the past. Figure 21 is intended to show various types of organizations where integrated 
product teams (EPT) have been used in the near recent past. These organizational structures are briefly 
discussed below. 

Engineering organizational types have been structured to achieve project goals in the most cost 
effective manner. As mentioned above, four of the most commonly used organizational structures are 
shown in figure 20. The functionally organized structure is frequently used when the product development 
is not too complex and the functional managers can achieve the necessary system design function in addi- 
tion to the functional operation of the organization. On the other hand, a certain product may require 
special attention such that a project specific leader is required. Again, if the project is not too large, then a 
light-weighted matrix organization can be suitable. In this case, representatives from some of the func- 
tional organizations usually support the project; in addition, the leader interacts with the functional manag- 
ers. If the engineering task is complex, then a heavy- weighted matrix organization is favored. The leader 
interacts formally and on a regular basis with the functional lead engineers and the functional managers. 
All other engineers work informally with the functional lead engineer and report technically to functional 
managers. This type of organizational structure has been very popular in the aerospace and automotive 
industry. The final organizational structure is the project organization. In this structure the lead engineers 
and the working level engineers are directly responsible to the leader. Their relationship to the functional 
manager is to maintain functional discipline but the functional manager is not technically responsible for 
their work. The leader interacts with the functional managers as needed. There has been a recent trend in 
the automobile industry to use the project organization as opposed to the matrix organization. The four 
organizational structures delineated here are basic, and many variations of these have been implemented. 




Figure 20. Typical organizations. 


37 
































Engineering organizational structures have been fine-tuned recently with the implementation of 
IPT’s. The IPT’s are a variation of a project team. Shown in figure 21 are three variations of IPT’s. The first 
team structure is of a type where the IPT is technically connected to the functional organization. The teams 
can be colocated or the members can remain in the functional organization. The functional managers are 
responsible for the technical engineering work, and the informal integration is within and between teams. 
The leader is responsible for activities associated with the system design function. This structure has been 
popular and very successful. In the second type, the IPT is connected to the functional organization through 
procedures and standards. The teams are located within the project, and the informal integration is within 
and among teams. Again, the leader is responsible for activities associated with the system design function. 
The functional manager maintains technical discipline but is not technically responsible for the engineer- 
ing work. The third type of organizational structure is where the IPT is completely independent of the 
functional organization. The teams are located with the project and the informal integration is within and 
among teams. The leader is responsible for activities associated with the system design function. There is 
no connection between the working engineers and the functional managers. This particular structure has 
proven to be unsuccessful in some cases. 

It has been learned that when engineering specialists are separated from the functional organization 
for more than about two years, there is an erosion of their technical expertise. Some organizations move the 
technical specialist back to the functional organization after about two years. 

4.1.5 Roles 

The system design function uses systems engineering discipline tools like QFD to transform 
the mission statement into a description of system requirements and a system configuration. These are then 
allocated to the other design functions. All system requirements must be integrated to ensure balance and 
compatibility of all interfaces. All other factors must be integrated into the total engineering effort to meet 
the cost, schedule, and technical objectives. 

The systems design function is responsible for the overall technical management and certification 
of the system. There must be technical interchanges with all contributing parties as well as requirements 
definition, management, analysis, and flowdown. In addition, there must be verification 
planning and audit, interface management, risk analysis and management, configuration management, etc. 
Again, the tools of the systems engineering discipline are applied to support these activities. 

The challenge of systems design function is to provide the best system that meets all the require- 
ments and provides a proper balance of performance, cost, reliability, safety, operability, schedule, and 
TRL. The systems engineering discipline plays an important role in this process where the discipline- 
specific tools are implemented to aid planning, to achieve design process control, and to provide the 
documentation of all critical process elements. The system design function is the responsibility of the 
leader, who is supported by the systems engineering discipline in planning, controlling, and documenting 
the process. 
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IPT Technically Connected to Functional Organization 



IPT Connected to Functional Organization Through Procedures and Standards 



IPT Completely Independent of Functional Organization 


Figure 21. Integrated product teams. 
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4.2 Technical Integration 


Technical integration is the fundamental fiber that goes through every aspect of the STS design 
process. It is accomplished with an increasing intensity as the design process progresses through the 
various stages. Technical integration will be illustrated using a symbolic representation; i.e., a model. In 
addition, there are various other factors that are known to enable it. These factors can be thought of as 
describing attributes of technical integration. In this section a model is provided for technical integration, 
along with a description of the enabling factors and a typical activities distribution. 

4.2.1 Technical Integration Model 

The T-model has been chosen to illustrate technical integration in this document. Helmut Horn 
(Peenemiinde Team) discussed the T-model for technical integration during Satum/Apollo era. Contempo- 
rary literature discusses the attributes and advantages of this model in today’s environment. This model has 
been called the T-model because it has vertical and horizontal components. The stem of the T represents 
in-depth discipline (or component) activities and penetration while the crossbar represents interactions; 
i.e., technical integration. The model, when applied to the space transportation design process, results in 
two specific levels of technical integration shown as parts of the T’s crossbar in figure 22. The upper level 
(i.e., above the dashed crossbar) of technical integration is known by the interchangeable names of system 
integration, formal integration, or top-level integration. The leader and his office are the primary facilita- 
tors and operatives of this level of integration. The emphasis of this level of technical integration is prima- 
rily upon the system aspects of the design process; i.e., the focus is on overall technical management and 
certification of the system. The concerns are delivering the product with a proper balance of performance, 
cost, reliability, safety, operability, schedule, and TRL. Technical integration is achieved through commu- 
nication and interaction with all contributing parties, customers, and similar interfaces associated with the 
design process. The continual purpose is to converge to a balanced product via managing and resolving 
conflict. All system related decisions and all system related technical conflicts are respectively made and 
resolved at this level. In addition, all system planning, control, and documentation related to the design 

T-model for Technical integration 


• Systems < — ► 

• Formal 

• Top Level 

— ~i— - — — — 

• Specific Discipline to 
Specific Discipline 



Integration is Everybody's Responsibility 


Figure 22. Technical integration — T-model. 
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process is maintained at this level. The level of intensity of the activities increases as the design process 
progresses through the various stages. 

The lower level of integration (i.e., below the dashed crossbar) is given by the interchangeable 
names of specific discipline to specific discipline, informal integration, or in-depth integration 
(see fig. 22). The emphasis of technical integration in the horizontal portion below the crossbar represents 
discipline-to-discipline or component-to-component interactions of the design process. The functional 
organizations are the primary operatives of integration for discipline-to-discipline aspects of the design 
process, while the engineering design functions (see section 4.3.1) are the primary facilitators of integra- 
tion for the component-to-component specific aspects of the design process. The vertical legs of the 
T-model can also denote activities of discipline engineers. It signifies that individual engineers must have 
in-depth discipline capability with a systems perspective. These engineers must be knowledgeable, aware, 
and responsive to their respective interacting disciplines, as well as the systems aspects of the process that 
they impact throughout the various design stages. 

The design considerations are the pedigree of input data, maturity of configuration, interactions, 
compatibility, sensitivity, uncertainty, etc. The focus is on the technical adequacy of all the discipline 
specific design attributes and how they horizontally integrate with other disciplines to achieve a balance of 
the allotted attributes for the specific design functions. This is accomplished through an iterative process. 
If proper balance cannot be achieved, then the design function must bring the conflict to the upper level for 
reallocation of requirements or some other system resolution. It is the responsibility of the discipline 
organizations to document and report their technical results. 

4.2.2 Technical Integration Enabling Factors 

The factors that enable effective technical integration include (1) an electronic communications 
system; (2) the internal connectivity of sizing programs that inherently connect certain disciplines 
(caveat — not a substitute for personal interactions among the specialists); (3) interactive team members 
having strong leadership that in turn fosters interactivity; (4) proper overview by leader, functional 
managers, advisors, etc., to ensure correct integration; and (5) interactive feedback of requirements, 
strategy/philosophy, and architecture. 

How does one know if proper technical integration is occurring? Throughout the process, manage- 
ment and participants must be very alert to the integration issues. Use a state-of-the-art communications 
system tailored to provide pertinent information to the participants. Check inputs and outputs required to 
ensure cognizance and understanding among design functions and disciplines. Determine the extent of 
continuous interactions by being aware of informal integration and have participants display integration 
activities and accomplishments. At each iteration, check to determine if the right problems are being worked, 
verify data trends, determine if uncertainty is converging, and have independent experts evaluate critical 
items. Throughout, check for consistency, compatibility, and convergence. 

4.2.3 Technical Integration Activities Distribution 

Throughout the various stages of the design process the distribution of the technical effort rate 
changes. Figure 23 delineates the scaled technical effort rate variation with scaled project duration. 
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The major total technical effort rate can be categorized into two groups: (1) Technical activities and 
(2) technical integration. Technical activities include all design function and discipline engineering and 
other technical efforts required to complete the project. Technical integration is composed of formal and 
informal integration. From figure 23, it can be seen that the technical activity peaks about midway through 
the project where the major expenditure of design function and discipline engineering effort occurs. The 
technical integration starts off at a low level, ramps up, and then levels out throughout the project. The 
major formal and informal balancing acts are being achieved during this part of the project. The formal 
integration tends to increase at the end of a project, since the project comes together as a validated hard- 
ware product. In summary', the rate distribution shown in figure 23 represents a typical distribution of a 
representative project. In each specific engineering project, the distributions may be different, however, if 
there is a significant difference, this difference should be studied to ensure that there is an appropriate focus 
of all the activities. 



Figure 23. Technical integration — activities distribution. 
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4.3 Characterization Model 


A symbolic representation of the launch vehicle design process is developed in this section. It 
consists of three categories of compartmentalization. They are hardware/software subsystems, design func- 
tions, and discipline functions. After compartmentalization, the T-model of technical integration is applied 
to the subsystems and to the design and discipline functions. All this enables the symbolic representation 
and enhances the capability to achieve technical integration. The features of hardware/software subsystems, 
design functions, and discipline functions are delineated. In addition, the Ixl and NxN matrices and the 
balancing act are illustrated. This is followed by a description of the launch vehicle system. This descrip- 
tion illustrates each design function, connections between design functions, how they are enabled by vari- 
ous discipline functions, and the launch vehicle system Ixl and NxN matrices. In addition, this section 
includes what tasks must be achieved, what product attributes are developed, and what decision gates must 
be passed. All of the aforementioned is discussed in a parallel fashion for each design function. Also, the 
NxN matrix, WBS’s, and tasks in reference 2 are included to show the relationship to the process symbolic 
representation. 

4.3.1 Features of Description 

The success of the design process depends upon achieving technical integration and achieving it in 
an effective and efficient manner. Initially, the principal engineers from the systems design function and the 
principal engineers from the functional organizations accomplish compartmentalization (see section 2.0). 

The first category of compartmentalization consists of dividing the STS program into the launch 
vehicle system, payload interfaces, and operations system. Then the launch vehicle system is further 
divided into subsystems and so on, as illustrated in figure 24. Each division results in a “system,” and there 
are supporting design functions and discipline functions for each system. The design and discipline func- 
tions will be illustrated below. The information flow associated with these systems consists of allocations 
from the parent system and suballocations to the lower-level subordinate systems (subsystems). Then there 
is also information flow associated with interface requirements. It can flow from the parent system, from its 
peer (i.e., mating interfaces, subsystems) and from its lower-level subordinate systems. In addition to those 
types of information flow between these systems, there are also interactions. The interactions are physical, 
functional, and informational. It is of paramount importance to track and account for all interface interac- 
tions. These can be determined through experience, analysis, test, or simulation. The information flow and 
interactions in this category of compartmentalization are important aspects of technical integration. 

The second and third categories of compartmentalization pertain to mechanics of how the design 
specifications of the system are actually achieved. To further illustrate the design process, a distinction 
must be made between the sometime misunderstood design functions (the second category) and discipline 
functions (the third category). The distinction between design functions and discipline functions is illus- 
trated in the following example. First, consider the design of the fuel tank subsystem (see the fuel tank 
subsystem 2.2.3.2 in fig. 25). Recall, the fuel tank system design specifications are the responsibility of the 
fuel tank system design function. It is shown in figure 25 at the top of the “stack” and is designated as 
2.2.3.2.0.1 From the figure, it can be seen that the entire fuel tank system design activity is supported by 
other design functions in the corresponding stack. The design functions design from their own perspective 
but with cognizance of the other design functions in the stack. This aspect of technical integration that is 
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(Selected compartmentalization subsystems shown as an example) 

Figure 24. Launch vehicle hardware subsystems compartmentalization. 


associated with the stack will be discussed in a following section. Ideally, each design function in the stack 
provides hardware/software design specifications (that satisfies the allocated requirements) to the system 
design function. In turn the system design function is responsible for developing integrated fuel tank 
system design specifications. The following is a typical list of the design functions that support the fuel 
tank subsystem design: 

• Fuel tank systems 

• GN&C (for slosh baffle requirements) 

• Structures 

• Thermal 

• Avionics 

• Materials 

• Manufacturing 

• Other systems. 

The hardware/software specifications delivered by design functions are designed by a person or 
persons called designers. The designer has the ultimate responsibility for specifying the final hardware/ 
software configuration along with the associated attributes. Designers conceive (hypothesize, synthesize) 
candidate subsystem configurations that are then analyzed to see if they will successfully perform as 
desired. Designers’ products are drawings and software specifications that define their subsystem. For the 
fuel tank system example, the specifications (drawings, manufacturing instructions, etc.) would be those of 
all tank structure, tank thermal systems, propellant utilization system, and propellant conditioning system. 
In addition, it would also include the associated design attributes such as performance, cost, reliability, etc. 
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Figure 25. Fuel tank example: Subsystems, design functions, and discipline functions. 
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In summary, what the designer does is called the design function for his or her respective design 
function. As can be seen, there are design function “stacks” corresponding one to one to each hardware/ 
software subsystem. The same principle applies as the subsystems are further compartmentalized into 
sub-subsystems, components, etc. 

On the other hand, discipline functions (third category of compartmentalization) are technical areas 
of specialty and expertise. Discipline functions perform analyses, tests, and simulations of a given design 
concept. The discipline functions support the design functions to achieve the desired attributes, and they 
reside on the design function “plane.” This particular aspect of technical integration will also be discussed 
in a following section. A typical list of disciplines includes the following: 

• Structural analysis 

- Structural dynamics 

- Stress 

- Durability 

— Vibroacoustics 

• Control system analysis 

• Etc. 

It is possible for an engineer to have both a design function role and a discipline function role. This 
is uncommon in structures, but in some other areas such as control, the same engineer may both conceive 
(hypothesize, synthesize) a control system and perform analysis on that system. That engineer can be 
found at different locations on the plane depending upon the activity engaged in at the time. 

In summary, design functions can be represented as planes that produce the design specifications. 
On each plane are the interacting discipline functions needed to support the development of those specifi- 
cations. There is a “stack” of design function planes associated with each system, subsystem, etc. The top 
“system” plane of the stack is responsible for integrating the other design functions in the stack and is 
responsible for providing the hardware/software specifications for its respective system or subsystem. Dis- 
cipline functions reside on the plane of the specific design function that they are analyzing or testing. If 
they are involved in multiple subsystems, they reside on more than one plane. (For example, a stress ana- 
lyst doing work on both the fuel tank structure and the main engine structure would find his respective 
activities on the fuel tank structures plane and the main engine structures plane.) 

In the previous discussion, the fuel tank system was addressed to illustrate the three categories of 
compartmentalization. In the following discussion the focus will be on the launch vehicle system (see 2.0 
on fig. 24). In this situation, the top-level system plane represents the system design function for the total 
vehicle system. The designer in this case is the leader who has the ultimate responsibility for producing the 
total vehicle drawings in addition to hardware/software specifications. Also resident on the system plane is 
the discipline of system engineering that performs the discipline functions related to design process plan- 
ning, control, and documentation. 

After the first and second categories of compartmentalization are completed, activities on the sys- 
tem plane begin with a listing of hardware and software design products along with the required associated 
tasks to produce these products. The design functions promote the necessary integration and communication 
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to effectively and efficiently execute the tasks to produce design specifications that meet the allocated 
requirements. To enable the determination of design functions, consideration is given both to arrangements 
that tend to decouple the various design functions and to arrangements where there is a logical grouping of 
multidisciplinary activities for each design function. Figure 26 represents typical arrangement of design 
functions for the launch vehicle. The launch vehicle design process consists of the following design 
functions: system, aerodynamics, trajectories/G&N, controls, structures, thermal, propulsion, avionics, 
materials, manufacturing, and others. It can be seen that all of the design functions are overarched by the 
systems design function. Each of the design functions is enabled by discipline functions that have activities 
that support the development of the design specifications. The discipline function activities include 
analysis, simulation, ground and flight test verifications, etc., to accomplish the design tasks. 

The attributes and specifications of each of these design functions are attained through the 
multidisciplinary activities of all the discipline functions supporting that design function. These attributes 
and specifications must satisfy the system requirements and not conflict with any attributes, requirements, 
or constraints of the other design functions. The products, obtained via the design functions, are the launch 
vehicle design drawings and specifications, other associated criteria and requirements, and constraints that 
relate to the launch vehicle hardware and software. 

All design function and discipline function activities must be technically integrated. This is accom- 
plished by both formal and informal technical integration, represented in figure 26. The rectangular conduits 
represent the vertical formal technical integration. The circular conduit represents the vertical informal tech- 
nical integration. In addition, there is also in-plane informal technical integration. In-plane informal technical 
integration is defined to mean multidisciplinary technical integration activities on a design plane. 

The formal vertical integration represents the flow of information downwards and upwards. The 
downward flow of information is from the systems design function to the other design functions. This 
information mainly consists of subsystem specific requirements, architecture, philosophies, procedures, 
and criteria and is represented by the downward pointing arrows. The upward flow of information is from 
all the design functions to the systems design function. This information mainly consists of the attributes 
(characteristics of the design to be compared to the allocated requirements, etc.) of the design from the 
design functions and is represented by the upward pointing arrows. Formal in-plane integration occurs 
within the systems design function. This integration pertains to achieving balance among the system 
attributes and insuring compatibility to the requirements, managing and resolving conflict between design 
functions, and overall system engineering management, certification, and documentation of the entire 
system. 


The informal integration is both vertical and in-plane. The vertical informal integration (i.e., the 
circular conduit) represents a flow of information that is both upwards and downwards. The information 
flow is between design functions and is represented by the arrow pointing upwards and downwards. Notice 
that this information does not go to the systems design function. This type of information flow results 
because of the iterative nature of the design process and the fact that the design functions are coupled; 
i.e., the attributes of one design function may affect the attributes, requirements, or constraints of other 
design functions. Thus, the final attributes from all the design functions must be balanced (i.e., mutually 
compatible) and satisfy all the allocated requirements. Finally, there is also informal in-plane integration. 
This flow of information results from the multidisciplinary activities that occur within each design 
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Figure 26. Technical integration of system, design, and discipline functions. 


function. Again, these activities are iterative, and they are considered balanced when the attributes satisfy 
the system level requirements and do not conflict with the attributes, requirements, or constraints of the 
other design functions. 

All information flow is accounted for and controlled through the utilization of the Ixl and NxN 
matrices (see fig. 27). The Ixl matrices are associated with hardware/software interfaces and the NxN 
matrices are associated with the design and discipline functions. As shown on the figure, the Ixl matrices 
pertains to input and output data flow associated with the physical, functional, and informational hardware 
/software subsystems interfaces. This type of information is usually contained in interface control docu- 
ments (ICD). Similarly, the NxN matrices pertain to input and output technical data flow associated with 
interacting design and discipline function activities. This aspect of the design process characterization 
provides a residence and a placeholder for information associated with the design process. 
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Figure 27. Matrices of input/output data flow. 
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Technical integration is a balancing act. At the top level the design and the operational plan must 
balance the program requirements (see fig. 28). During the design process there are numerous trade studies 
where the attributes between various design function planes are balanced to achieve the best design. 
(Individual engineering design functions will be interchangeably denoted as planes in some parts of this 
narrative. For example, the aerodynamic design function may be denoted as the aerodynamic plane.) 
In a specific plane there is also multidisciplinary balancing to achieve optimal attributes that satisfy the 
requirements. Trade studies that drive out the differences in design alternatives constitute a significant part 
of the design process as managed by the leader on the system plane. Because of the strongly coupled nature 
of launch vehicles, trade studies are usually numerous and must be performed at a sufficiently detailed 
level to reveal the differences in the alternatives. Trade studies usually involve multiple design functions. 
How well the balancing is achieved determines the success of the product. Pye states, “Any of these forms 
of energy is capable of producing changes, changes in things; more exactly, redistribution of 
matter.... Now whenever a change is made by the passage of energy and a result is left, this event takes 
place in a group of things. Things are always together. They do not exist separately. ... All you can do, and 
that only within limits, is to regulate the amounts of the various changes. This you do by design.” 
He states further, “The requirements for design conflict and cannot be reconciled. All design for devices 
are in some degree failures. . . The designer or his client has to choose to what degree and where the failures 
shall be...” 6 Figure 28 also shows the function of system analysis and integration in performing the 
balancing act. The various discipline functions provide sensitivity data that are used to perform trade 
studies and technical integration. Through the use of assumptions, analyses, simulation and testing, and 
using the core capability of the organization, these design tradeoffs can be made and aternative 
design solutions achieved. These solutions in general will be suboptimum and can consist of several 
compromises of the original requirements. Understanding and accounting for the balancing act are keys 
to successful design. 



Figure 28. Design process balancing act. 
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Technical, cost, and schedule risks must be actively managed throughout development. Active risk 
assessment is an essential element of the design process. Failure mode analyses and risk/consequence 
assessments are done for each design alternative. A technology assessment for each design alternative 
identifies technology development required, along with the risk associated with maturing the technologies 
to an acceptable level. 

In the compartmentalization process described above, the intent is to take advantage of weak 
coupling between design functions and between discipline functions. This approach enables the design to 
proceed at design function sublevels such as structures, propulsion, avionics, etc., and by the various tech- 
nical disciplines. However, this assumption results in a suboptimum design from two standpoints: (1) The 
total system is not optimized since the design is consummated at the element, subsystem and component 
level. In other words, the assumption is that if all the parts are optimized, when they are put together the 
system will be optimized. The degree that this is true depends upon the coupling between each of the 
elements, subsystems, and components. (2) Elements, subsystems and components themselves are never 
truly optimized due to the constraints levied, as well as the trades and balancing acts that must be 
accomplished to make the system work. 

The compartmentalization process also facilitates the allocation of requirements, etc., and the 
definition of tasks. An orderly set of clearly defined discipline tasks must be developed. These tasks can be 
discipline specific or multidisciplinary, and they must be timely (their association to the critical path should 
be determined). At the system level, design and interface requirements are subsequently allocated to the 
design functions, and these allocated requirements lead to metrics for the design function gates. It is most 
efficient and effective when the system design function develops the requirements in conjunction with the 
other design functions and is then reinforced by the discipline functions. 

As illustrated in figure 9, a key aspect of the design process is the re-integration of design results 
from the compartmentalized discipline functions, design functions, and subsystems. In the ideal situation 
all of the discipline function results are integrated to support the design functions for each subsystem. The 
design attributes would be integrated by the system design functions via trade studies with the balancing 
act. Then all the subsystems are integrated (assembled) to achieve the launch vehicle assembly. During the 
re-integration activities, the major aspects of technical integration are to ensure design attributes satisfy 
requirements, constraints, etc.; interface requirements are met; interactions are appropriately accounted; 
significant nonlinearities are included; sensitivities, uncertainties, and margins minimized; risks minimized, 
mitigated and managed; verification is adequately achieved, all certification requirements defined; flight 
and operational constraints minimized; and all issues and concerns resolved and documented. 

4.3.2 System Design Function 

Shown in figure 29 is the design process technical integration with a focus on the system design 
function. The illustration delineates the relationship between the system design function and the other 
design functions. In addition, it shows the work/information flow process that is supported by key system 
decision gates required to develop and assess the system attributes. The details of all the above are 
discussed in this section. 
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Figure 29. Design process technical integration — system design function. 


The launch vehicle process as practiced is sequential. Conceptually, one could “cut and try” to 
achieve a design; i.e., build, test, and fix a product until it operates satisfactorily. For launch vehicles, 
however, because of the system complexity, challenging performance requirements and environments, the 
number and depth of technical disciplines, etc., the design process has evolved sequentially in order to 
achieve design efficiency and technical fidelity. For example, as previously discussed, trajectory outputs 
are inputs to control analyses, control analyses outputs are inputs to loads, etc. 

Note: The systems design function is a process that involves formal technical integration of results 
from all the other engineering design function planes supported by the systems engineering discipline. The 
goal is to deliver a verified product that satisfies all the system requirements. This report does not describe 
the system design process in detail, but provides a top-level overview to show key features as they relate to 
the total vehicle design process. 

4.3.2.1 System Design Function Plane. The systems design function is the overarching engineer- 
ing activity that ties together all the other design function results and subsystem interface activities. The 
key features of the systems design function along with the associated connectivity are shown in figure 30. 
This figure will be referred to as the system plane. The systems design function must ensure that the design 
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concept becomes formally integrated as a balanced system product that has been validated to satisfy all the 
top-level system and all other engineering design function requirements and constraints. Top-level systems 
requirements and constraints are developed, analyzed, tested, balanced, formally integrated, and validated 
by the system design function. All other design function requirements and constraints, in contrast, are 
developed, analyzed, tested, balanced, informally integrated, and validated within and between the other 
design functions and then formally integrated into the systems design process. Most of the top-level system 
requirements and constraints are derived from the given mission statement, while others are determined 
from experience. The requirements and constraints derived from the mission statement are somewhat 
inflexible. The major top-level system requirements are performance, cost, schedule, TRL constraints, 
reliability, safety, and operability. 
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Figure 30. System design function plane. 


Throughout the duration of a project all the requirements and constraints are continuously assessed 
and refined. In addition to the requirements and constraints, the project must also develop the system 
architecture, certain philosophies, procedures, criteria, and ground rules. The latter are flexible and meant 
as guides for the engineering development. Subsequent to the above, the associated system parameter 
matrix with associated uncertainties is defined. The system architecture and its associated parameter 
matrix with uncertainties are determined in conjunction with all the other engineering design functions. 
The system architecture is then evaluated and refined throughout the design process. The resulting 
attribute of performance, associated with the system architecture(s), must meet the requirements, 
constraints, philosophies, procedures, criteria, and ground rules. Other types of system analysis (e.g., cost, 
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reliability, etc.) are conducted for the architectural concept(s) to determine those remaining system 
attributes. As concepts are being selected (in some situations there can be more than one concept), 
requirements relating to the most promising concepts are allocated to all the other engineering design 
functions. These allocations include the design specific requirements or metrics for each engineering 
design function. Requirements are refined and updated throughout the design process; i.e., from 
conceptual design through preliminary' and detail design. As the design progresses, the requirements can 
change as a result of a top-level change or because of the engineering balancing act. 

Throughout the entire design process, the system design function and all other design function 
knowledge bases are continually increasing while the uncertainty is decreasing. All the data relating to the 
selected architecture(s) are assessed by systems and discipline engineers on the system plane to assure that 
all the requirements, constraints, philosophies, procedures, criteria, and ground rules are satisfied. In fact, 
the design process is iterated until all requirements are satisfied. In addition to determining and assessing 
the system attributes, the systems design function is also responsible for other activities related to the 
system. Some of these include risk determination, assessment, and management; requirement allocations, 
management, integration, and redistribution; tracking system design performance metrics; 
configuration management; etc. 

Thus, the process illustrated on each design function plane is iterative, consisting of the following steps: 

• Determine requirements and guiding philosophy 

• Synthesize a candidate design to meet requirements 

• Analyze the candidate design to determine its attributes (performance, cost, reliability, etc.) 

• Compare attributes to requirements 

• Modify the candidate design if attributes do not meet requirements 

• Compare new attributes to requirements 

• Continue iterations until design satisfies requirements. 

If a design meeting requirements cannot be found, a rebalance or modification of requirements is 
necessary, as discussed earlier. Throughout the iterative process, all pertinent interactions with other 
design functions are maintained. 

In the past the cost of a launch vehicle project usually has not been a serious design consideration; 
performance was always the primary design metric. However, in the next generation of launch vehicles, 
cost will be one of the most serious design considerations. Bringing cost into the design equation is not 
simple in that it must inculcate all the various contributing parameters, including infrastructure, 
manufacturing, operations, engineering, etc. These relationships to the design are not all quantified and 
must be dealt with using judgments, etc. Obviously, the best approach would be to have cost-estimating 
relationships for all the various design parameters. This is not possible since credible cost-estimating 
relationships are not available for most of the aforementioned; however, use must be made of those that are 
available. For example, cost associated with the design itself can be broken out in terms of engineering 
effort (analysis, testing, simulations, etc.), facilities (computational, staff, manufacturing, testing, etc.), 
materials, manufacturing, verification, etc. It should be noted that cost is strongly driven by the require- 
ments imposed, whether they be top-level project requirements (e.g., payload, performance, turnaround 
time, reliability, etc.), formal discipline-specific criteria, or documentation and traceability requirements. 
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These should be tightly controlled since they can have major cost impacts. If the aforementioned were the 
only costs, then the job would be fairly tractable; however, the vehicle design has a major impact on cost 
through operations. The vehicle combined with the mission requirements interacts in a very complex 
manner with operations. This can be said since it is clear that operations has to do with receiving the 
vehicle (usually by elements), processing and assembling, check out, launching, communications (voice 
and telemetry), maintainability (inspections, refurbishment, etc.), and availability (turnaround). The 
vehicle design and margins impact the launch constraints (allowable winds, temperatures, etc.), and the 
procedures for each subsystem. As a result, operations and sustaining engineering manpower carry a 
significant cost impact, depending on the vehicle’s robustness and autonomy. 

Designing for cost, therefore, implies metrics and guidelines that effect trade studies between 
operational design and vehicle design. These include but are not limited to — 

• Requirements/criteria 

• Robustness/reliability 

• Infrastructure (facilities, etc.) 

• Manufacturing 

• Materials 

• Maintenance 

• Processing 

• Assembly 

• Checkout and verification 

• Launch procedures/constraints 

• Communication (voice and telemetry) 

• Software. 

Historical data help in formulating the cost models; however, cost specialists must assist the 
designer in understanding the cost drivers and achieving a cost-effective design. One warning: Do not do 
the cost assessment at the end. Make it a part of the up-front design process, and track it on the system 
plane. 


All of the activities associated with the aforementioned are accomplished via formal and informal 
technical integration and orchestrated by the system design function. This technical integration is achieved 
with the utilization of Ixl and NxN information flow matrices as discussed in section 4.3. 1 and illustrated 
in figure 27. Recall the Ixl matrices are associated with information flow related to hardware/software 
interfaces and the NxN matrices are associated with information flow related to the design and discipline 
functions. The specific details associated with both of these types of matrices are discussed below. 

4.3.2. 1.1 Ixl Matrices. Figure 27 illustrates two types of information flow matrices that help in the 
characterization of the design process. On the lower left is shown an Ixl matrix corresponding to the 
subsystem tree. Ixl matrices represent information flow associated with the subsystem tree interfaces. An 
example expansion of an Ixl matrix is shown in figure 31. It represents interface information flow for the 
launch vehicle and its next tier of subsystems. The launch vehicle is shown in the upper left block, with its 
next tier subsystems on the remainder of the diagonal. Elements on the horizontal rows contain outputs 
from the entity on the diagonal, and elements on the vertical columns contain inputs to the entity on the 
diagonal. 
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The first diagonal element contains the system (or subsystem) for which the Ixl matrix is con- 
structed. The remaining diagonal elements are the subsystems (or sub-subsystems) in the next lower tier of 
the tree. Along the top row are the interface requirements imposed by the system on its subsystems. The far 
left column then feeds back the description of the as-designed subsystem interface to the system; i.e., what 
the subsystem design has accomplished in response to the interface requirements from above. 


Interactions Among Hardware Elements 



Propulsion System 
Interface Requirements 
to Structures 


Structures 
Interface Description 
to Propulsion System 


: ll_". ' : • • 

if Thermal 
Systems 


OUTPUTS 


Propulsion System 
Interface Description 
to Structures 


Figure 3 1 . Ixl matrix for launch vehicle. 


The remaining off-diagonal elements contain interface requirements and interface descriptions 
among peer subsystems along the common tier. Note that the information flow between any two entities 
takes a clockwise path on the matrix. In the case of peer subsystems, there are two concurrent interface 
information flows occurring (represented by two shades on the inset blocks). One involves interface 
requirements of subsystem A on subsystem B, along with B’s interface description fed back to A. The 
other flow involves requirements of B on A, along with A’s interface description fed back to B. 


56 





Note that there are numerous Ixl matrices. There is an Ixl matrix associated with each system or 
subsystem that is divided into lower tier entities on the tree. Thus there is an Ixl matrix for each subsystem 
as we proceed down the tree to its next-to-last tiers. The parts on the last tiers of the tree are sufficiently 
simple that no further subdivision is required. These parts are simple enough to be designed by an 
individual designer, using handbooks, standards, etc. These last-tier parts appear on the lower diagonal of 
Ixl matrices, but they do not have their own Ixl matrices where they would appear in the upper left element 
of the matrix. 

4.3.2. 1 .2 NxN Matrices. On the lower right of figure 27 is shown an NxN matrix corresponding to 
the stack of design function planes and the discipline function activities resident on the planes. NxN matrices 
represent information flow among the design functions and the discipline functions. An example NxN 
matrix is shown in figure 32. The example in this case is the launch vehicle system with its associated 
design functions and disciplines. Note that the launch vehicle system plane is represented by the upper left 
element of the matrix, and the remaining lower design function planes are represented on other diagonal 
elements. 

NxN Matrix for Launch Vehicle 



Figure 32. NxN matrix for launch vehicle. 
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The input-output pattern is like that of the Ixl matrix; i.e., outputs of a diagonal element are on its 
horizontal row, and inputs to the element are on its vertical column. Thus, the entries in the first row are the 
outputs from the launch vehicle system plane (allocations of requirements, architecture, and philosophy) 
that are inputs to the lower design function planes. This is the information that flows down the respective 
conduits of the stack. The entries in the first column are the outputs from the lower design function planes 
(attributes) that are inputs back to the launch vehicle system plane. This is the information that flows up the 
attribute conduit of the stack. The remaining off-diagonal elements contain information flow among the 
lower design function planes, as represented by the round vertical conduit of the stack. An example entry is 
shown for the output from aerodynamics that is input to thermal. 

There is an NxN matrix associated with each design function stack. Thus, there are many NxN 
matrices since there is a design function stack for every element on the subsystem tree whose design 
involves multiple design function activities. 

An example of a related NxN matrix from reference 2 is given in Appendix A. 

Inclusion of Ixl matrices and NxN matrices with the subsystem tree and design function stacks 
provides locations or placeholders for the technical information that must flow among the participants in 
the design process. This characterization also suggests a framework for an electronic information and 
communication system to enable efficient and concurrent interactions throughout the process 
(see section 5.2.4). 

4.3.2.2 System Gates. The decision gates for the system design function are shown in figure 33. 
The inputs to the system design process are the mission requirements, constraints, and system philosophy. 
The outputs are the system description, attributes, and operations plan. There must be a proper balance 
among the requirements, constraints, vehicle design and associated attributes, and the operational plan. 
The system gates are the locations in the project where the system attributes of performance, cost, reliabil- 
ity, safety, schedule, operability, failure modes, and TRL are compared to the requirements, 
constraints, philosophies, procedures, criteria, and ground rules. If the comparisons are favorable 
(i.e., yes), then the design process is completed. On the other hand, if the comparisons are unfavorable 
(i.e., no), then there must be another design iteration. This process is repeated until the design is balanced 
with the attributes satisfying the requirements, constraints, etc. 
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Figure 33. System design function gates. 


The systems design function must provide the project overview to achieve and enforce proper 
balance. The balance can be accomplished by modifying the design, operations plan, requirements, con- 
straints, philosophies, procedures, criteria, and ground rules. This is achieved through formal technical 
integration between and among the system and other design function planes. To achieve balance, all the 
results (i.e., attributes) are analyzed and assessed through informal technical integration on the system 
plane. If balance is achieved, the design is completed. System design and integration are completed when 
the attributes of performance, cost, reliability, safety, schedule, operability, and TRL satisfy the project 
levied requirements, constraints, philosophies, procedures, criteria, and ground rules. If balance is not 
achieved, the conflict must be resolved by modifying the vehicle design, requirements, constraints, opera- 
tional plan, or other influencing factors. The process is iterated until balance is achieved. The final major 
outputs of the system design and integration process are the following: (1) Description of system with 
attributes, (2) balance between attributes and overall requirements, and (3) operational process of how to 
fly the vehicle. The formal and informal integration are a continual process in the design project, and 
results are documented at major reviews. 

4.3.2.3 System Design Tasks. The definition of vehicle design tasks associated with the activities 
of the system design function begins with the definition of the mission statement. After the 
compartmentalization activity, the principals of the system design function, all the other design functions, 
and discipline organizations delineate all the major vehicle design tasks. The tasks associated with the 
system design function can be categorized into five major groups that are as follows: (1) Develop engineer- 
ing design activity plan; (2) analyze, allocate, and manage subsystems and requirements; 
(3) perform system analysis; (4) integrate for balanced design product; and (5) verify system design. The 
specific tasks associated with the aforementioned major groups as shown in table 1 are discussed below. 
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Table 1 . System design function tasks. 


Activities 

Interactions 

Tasks 

1. Engineering design 
activity plan 

Program office 
Design functions 
Discipline functions 

1. Develop the engineering organizational structure. 

2. Establish formal and informal communications process. 

3. Develop schedule of engineering activities with associated 
deliverable products. 

4. Establish WBS. 

5. Document and disseminate plan; include mission statement. 

2. Allocation and 
management of 
subsystems and 
requirements 

Design functions 
Discipline functions 

1 . Consult with project office to establish top-level system 
requirements, philosophies, and constraints. 

2. Assess and compartmentalize systems into subsystems and 
elements. 

3. Determine and allocate performance, cost, reliability, operability, 
schedule, and TRL requirements to design functions. 

4. Acquire and formally allocate discipline criteria. 

5. Document and disseminate all requirements. 

3. System analysis 

Design functions 
Discipline functions 

1. During concept selection phase, define concepts; apply sizing 
program to evaluate and refine concepts; determine sensitivities; 
and identify new technologies required for each concept. 

2. Develop system parameter matrices and associated uncertainties. 

3. Determine system derived requirements and impose discipline 
derived requirements. 

4. Determine system attributes from systems analyses. 

5. Assess configuration and subsystems to verify conformance to 
all requirements. 

6. Establish failure modes and perform a risk assessment. 

7. Continue analyses throughout the project duration. 

8. Document and disseminate results. 

4. Integration for balanced 
design product 

Design functions 
Discipline functions: 

1 . Formally integrate and balance the various design function 
attributes to satisfy all systems requirements and discipline criteria. 

2. Manage conflict among discipline functions and between design 
functions to resolve all issues. 

3. Perform trade studies as required. 

4. Manage interfaces and changes. 

5. Document and disseminate results. 

5. Verification 

Design functions 
Discipline functions 

1 . Develop verification plan (analysis and ground/flight tests). 

2. Audit verification process. 

3. Correct anomalies. 

4. Document results. 

5. Validate system during developmental flight tests. 

6. Implement operational plan compatible with the verified system. 

7. Document and disseminate verification plans, corrective actions, 
and operational plans and procedures. 


43.2.3. 1 Task 1 — Engineering Design Activity Plan. Initially the type of organizational structure 
must be determined. The various types are delineated in section 4. 1 . Subsequently, the details of the formal 
and informal communication process are set up consistent with the organizational structure selected. This 
includes the chain of command, electronic communication system and control, formal data reporting, 
security, and others. Then based upon the compartmentalization, a WBS system must be developed with 
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associated tasks to support the activities of all the engineering design functions. These WBS designations 
are then implemented to develop an electronic schedule of engineering activities and the associated 
deliverable products. An important feature of the schedule is the critical path along with associated uncer- 
tainty. When the above is completed, the plan should be documented and disseminated. 

4.3.23.2 Task 2 — Allocation and Management of Subsystems and Requirements. A major focus of the 
system plane relates to understanding the mission statement and then developing the top-level 
requirements, constraints, and architecture philosophies. This activity is important and continues throughout the 
duration of the design process with the greatest intensity initially. The significance of the top-level requirements 
as they relate to the mission statement and to the vehicle design and operation must be determined by consider- 
ing nominal conditions in addition to sensitivity and uncertainty analysis. These data will be applied to assess 
potential impacts from trade-study results. Usually, the top-level requirements are invariant; however, they can 
be changed if there is cause and there is not a significant compromise to the mission statement. 

The system is then assessed in order to compartmentalize it into appropriate subsystems and design 
functions. Then the system plane in conjunction with the other design planes determines the performance, 
cost, reliability, safety, operability, and TRL constraints that are to be allocated by the system plane to the 
other design planes. The system plane must also acquire discipline specific criteria for formal allocation. 
All these data are then documented and disseminated. Throughout the process, the system plane manages 
the configuration evolution so that the activities of the various design functions are coordinated. After 
preliminary design, a baseline is established, and all data are under formal configuration control. 

4.3.2.33 Task 3 — System Analyses. The system analysis pertains to determining performance, 
cost, reliability, safety, schedule, operability, and TRL design attribute values for the total system along 
with formal technical integration to resolve conflict in order to achieve a balanced system design. Initially, 
architectural concepts along with parameter matrices and their uncertainties are determined and then, by 
applying the sizing program, the concepts are assessed. Trade studies and sensitivity analyses are performed 
and the concepts are refined to achieve the performance requirements restricted to the constraints and 
program guidelines. The refined concepts may require new technologies; thus, these must be determined 
and evaluated. The number of new technologies required to achieve a concept then becomes a factor in the 
concept selection. As the refined concepts begin to converge, the system parameter matrices and associated 
uncertainties are matured. Then by applying those input data, systems analyses are conducted to determine 
the remaining system attributes; i.e., cost, reliability, schedule, and operability along with their uncertainties. 
Then all these results are applied to assess the architectural concept’s attributes in regard to conformance 
with all the requirements, constraints, guidelines, etc. The results are eventually applied in a decision 
model to numerically rank the architectural concepts to aid in the concept selection. 

After the number of concepts has been narrowed down, risk analyses are performed. The major 
focus of these analyses is technical, cost, and schedule risk. The failure modes are established as part of the 
technical risk analysis. 

The total system analyses delineated above are continued, and the system attributes refined throughout 
the design process. The other design functions provide attributes of their subsystems as input to the total 
system analyses. The objective of the analyses is to improve the quality of the values of the attributes and 
reduce the uncertainties. These data are applied as technical performance parameters that are used to track 
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the progress of the design and to make numerous decisions throughout the design process. These results are 
documented, controlled, and disseminated by the systems design function. 

4.3.23 A Task 4 — Integration for Balanced Design Product. The system plane facilitates informal 
and formal technical integration to achieve a balanced design product. The informal integration pertains to 
the technical integration on the system plane to attain balance among the system attributes. The formal 
technical integration is between all the design planes and the system plane. The focus of the integration is 
to obtain a balance of the attributes among the design functions to satisfy all the requirements, constraints, 
and discipline criteria. To achieve balance, sometimes it is required to manage conflict among design 
functions and between disciplines to resolve issues that cannot be resolved through informal integration. 
This may require a multiplicity of changes. The system plane must control and manage all changes as the 
conflict is being resolved. In addition, it must also control and manage all system interfaces. These inter- 
faces may or may not be part of the conflict resolution. All these data must be documented, controlled, and 
disseminated by the system plane. 

43.2.3.5 Task 5 — Verification. The system verification activity is the responsibility of the system 
design function, and it is supported by all of the other design functions and the discipline functions. Ini- 
tially, verification plans are developed. The verification can be accomplished by analyses, simulation, or 
test (ground /flight). It is then the responsibility of the system plane to audit the verification process. This 
is usually accomplished with the other design functions and discipline functions. When anomalies are 
discovered, corrective action is required. The corrective action can be accomplished by redesign or by 
requirement changes. The corrective action must be subsequently verified. The results of these activities 
must be documented and disseminated. 

The final verification is obtained from developmental flight tests. If significant anomalies occur, 
then a corrective redesign is required or an operational constraint is place on the system. These corrective 
changes are required to be verified. All of these results are required to be documented and disseminated. 

4.3.3 Aerodynamic Design Function 

The connection between the design process technical integration and the aerodynamic design func- 
tion is delineated in figure 34. This illustration depicts the relationship between the aerodynamic design 
function and the other design functions. In addition, it shows the work/information flow process that 
is supported by key aerodynamic decision gates that are required to develop and assess the 
aerodynamic attributes. The details of all the above are delineated in this section. 
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AERODYNAMICS 



Figure 34. Design process technical integration — aerodynamic design function. 


4.3.3.1 Aerodynamic Design Function Plane. This discussion describes the features of the 
aerodynamic design function delineated in figure 34 and its connection to the stack in figure 26. The 
aerodynamic design function interacts through informal integration mainly with the trajectory/G&N, struc- 
tures, thermal, and control design functions. However, the aerodynamic requirements and constraints are 
allocated through formal integration with the system design function (see fig. 26 and 35). These require- 
ments and constraints include the aerodynamic configuration, cost, schedule, etc. They are assessed with 
established aerodynamic procedures, criteria, and methods. Subsequently, the aerodynamic design process 
is initiated where analytic, empirical, numerical (CFD), and test methods are applied to determine the 
significant aerodynamic parameters and associated uncertainties. Initially, the aerodynamic force and 
moment coefficients are determined. They are used in the sizing/trajectory program and are continually 
refined and updated throughout the design process to support system performance analysis. The steady 
aerodynamic environments are the basis from which localized loads and compartment venting pressures 
are determined. The unsteady aerodynamic environments consist of determining aeroelastic stability, 
acoustics, overpressure, ground winds, and buffet design parameters. The aerodynamic heating environ- 
ment consists mainly of the radiation heat flux from the engine plumes and the convective heat transfer 
from the external flow over the launch vehicle during ascent and reentry. The plume electron profiles must 
also be determined. All the aerodynamic parameters and their uncertainties are implemented into the 
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design process in an iterative manner until there is convergence with the requirements and constraints 
allocated from the system plane. In some situations the allocated aerodynamic requirements and 
constraints are modified to achieve overall balance. This can occur when all other disciplines are formally 
integrated by the system plane or when the physics of the situation dictates. Eventually, the aerodynamic 
design attributes must satisfy the requirements and constraints. This is delineated with the gate shown in 
figure 35. Finally, the aerodynamic parameters and their uncertainties are verified in flight experiments. 



Figure 35. Aerodynamic design function plane. 


The aerodynamics parameters and induced environments design process flow diagram from 
reference 2 is shown in figure 36. It can be seen that there is a direct correlation with figure 35. The focus 
of aerodynamics design function shown in figure 35 is to illustrate formal and informal technical 
integration, requirements and constraints, procedures and criteria, parameter matrix and associated uncer- 
tainties, major design functions that are accomplished by the aerodynamic discipline along with associated 
connectivity, and the output design attributes. The focus of the aerodynamic design process shown in figure 
36 is the aerodynamic discipline activities along with the corresponding requirements, inputs, outputs, 
connectivity, and products. The NxN diagram of reference 2 (Appendix A) is representative of further 
delineation of the inputs and outputs associated with the aerodynamic design process. 
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Products 

• Aerodynamics 

• Acoustics/Overpressure| 

• Venting 

• Ascent Aeroheating 

• Base Heating 

• Entry Heating 

• Plume Effects 

• Launch Stand Effects 

• Parachute Design/ 

Requirements 


Figure 36. WBS 2.3 — aerodynamics and induced environments. 2 


These inputs/outputs show the correlation with other design functions, and they represent the 
product flow of figure 26. The corresponding tasks are shown in table 2. These tasks are related to accom- 
plishing specific aerodynamic design objectives. The tasks associated with figure 35 are the allocation of 
requirements, aerodynamic design, and verification. These tasks are further discussed in section 4. 3. 3. 3. 
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Table 2. WBS 2.3 — aerodynamics and induced environments task description. 2 


Inputs 

Tasks 

Outputs 

♦Projected ground rules and goals 
•Launch pad geometry 
•Preliminary design out emold line 
•Ground and ascent wind profiles 
•Atmospheric models 
•Launch stand ambient temperatures 
•Protuberance geometry 
•Engine placement geometry 
•Ascent trajectory sets (altitude, 
velocity, a, p histories) 
and engine operating conditions 
•Entry trajectories 
•♦♦Airflow history to inlet 
•Trajectory constraints 
•••Mach transitions 
•Structural deflections 
•Heating constraints 
"Wall/surface temperatures 
•Control weights, centers of gravity 
•Engine dimensional and operational 
characteristics 
•Turbine exhaust definition 
•On-pad effluent definition 
•••Rocket based combined launch 
(RBCC) exhaust conditions 
"•Forebody inlet performance 
requirements 

"•Transition mach number 
•Vehicle integrated OPS concept 
and requirements 
•Hazard analysis 

•Failure mode effects analysis inputs 
•"CIL inputs 

3.4.1 Aero design consultation 

3.4.2 Generate ascent aerodynamics 

3.4.3 Generate external pressure distributions 
3 4.4 Generate protuberance airloads 

3.4.5 Generate aero coefficients 
3 4 6 Generate aero stability derivatives 
3.4.7 Generate vehicle/stage entry aerodynamics 
3 4,8 Determine vent size and location requirements 

3.4.9 Determine compartment pressures 

3.4.10 Calculate compartment flow rates 
3.4 1 1 Generate ascent aeroheating histories 

3 4 12 Generate ascent plume heating histories 

3.4.13 Generate entry heating histories 

3.4.14 Determine aerothermal test requirements 

3.4.15 Specify trajectory constraints for heating 

3.4.16 Generate launch overpressure environments 

3.4.17 Generate ascent acoustics environments 

3.4.18 Generate entry acoustics environments 

3.4.19 Determine prelaunch wind effects 

3.4.20 Determine parachute system requirements 

3.4.21 Perform breakup/disposal analysis 

3.4.22 Generate plume electron profiles 

•Pressure vent sizes and locations 
•Moldline update including airframe/ 
engine design 

•Vehicle ascent aerodynamics 
•Heating indicators 
"Vehicle/stage entry aerodynamics 
•Engine inlet flowfield definition 
•External aerodynamic pressure 
distributions 

•Compartment pressures 
•Protuberance airloads 
•Acoustic/overpressure definition 
•Fluid dynamic loads (buffering) 
•Ascent aero heating histories 
•Entry aero heating histories 
•Compartment flow rates 
•Plume heating environments 
•Guidance and control 
instrumentation locations 
•Airloads on propulsion elements 
•"Engine installed thrust 
"•Forebody pressure recovery 
and flow field history 
•Aerothermal test requirements 
•Plume electron profiles 
•Ascent and descent pressure 
distributions 
♦Heating and pressure 
instrumentation requirements 
•Sonic boom overpressure 
•Test requirements to include 
instrumentation 

Tools: 

• Computer codes: CEC/TRAN72, SPF/2, SIRRM, RAMP2, 
RAVFAC, BLIMPJ, MOC, SPP, LANMIN, MINIVER, Various 
CFD codes, etc. 

•Wind tunnel data 

• Historical ground and flight test data base 


Key: • ElV, reusable launch vehicle (RLV), and RBCC 

- RLV and RBCC 
«" RBCC only 


4.3.3.2 Aerodynamic Gates. The decision gates associated with the aerodynamic design function 
are shown in figure 37. It can be seen that the inputs are from the system plane and the aerodynamic 
discipline, plus there are interactions from other design functions. The outputs are the aerodynamic design 
attributes, and they must satisfy the system requirements on the aerodynamic design function plane. This is 
shown with the gate in figure 35. The decision gates shown in figure 37 relate to specific aerodynamic 
design needs and requirements; e.g., force and moment coefficients, acoustics, heating, etc. The data 
related to each gate are determined by aerodynamic designers via discipline analyses and testing. During 
this process, the aerodynamic designer must also be aware of the overall system requirements of cost, 
reliability, TRL, etc. The aforementioned data are the aerodynamic parameters and induced environments. 
Each of these quantities is determined in an iterative fashion. As the aerodynamic configuration begins to 
converge, metrics for the various gates also converge. The metrics are determined through formal technical 
integration of all the relevant design functions. These metrics then become the design targets or require- 
ments for the aerodynamic designer. As the design proceeds, some of the metrics may change because of 
unforeseen impacts. This can result in another design subiteration. When all the gates are satisfied, the 
aerodynamic design is complete. The aerodynamic design is finally validated with data obtained from 
flight experiments. Operational constraints or a delta redesign may be required if the flight data indicate a 
serious operational impact. 
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4.33.3 Aerodynamic Design Tasks. The aerodynamic design function begins with the determination 
of the aerodynamic forces and moments to be used in the trajectory analysis and with the determination of 
the acoustic and blast overpressure environments to be used for environmental impact assessment. As the 
design matures, more and different aerodynamic parameters are needed for other aspects of launch vehicle 
design (see fig. 35). These parameters and their uncertainties are determined in an iterative fashion through 
the design process and continually matured. A summary of the aerodynamic tasks is shown in table 3. 

4.3.3.3.1 Task 1 — Requirements Determination and Allocation. This activity is accomplished by 
the aerodynamics design function with the support of the system design function and other design functions 
and disciplines as shown in table 3. In addition to performance, the overall vehicle aerodynamic configura- 
tion is determined from many factors, with cost and operational considerations being significant. The 
aerodynamic design procedures and approaches are then established along with various design criteria. 
Specific metrics are determined for the decision gates. These metrics can change as more knowledge is 
acquired about the configuration and when additional constraints evolve from other design functions. 
Eventually, the metrics converge, and they become the targets for the aerodynamic designer. At this point 
the metrics are maintained at the system level and are under configuration control. Initially the technical 
integration is formal, but as the vehicle design advances, it becomes predominately informal until the 
aerodynamic attributes satisfy the requirements. These final attributes flow upwards to the system plane; 
i.e., formal integration. There are some aerodynamic parameters that are not allocated. The configuration 
and the associated physics (e.g., plume radiation heating, ignition overpressure, and others) determine these 
parameters. 
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Table 3. Primary tasks for aerodynamic design function. 


Activities 

Interactions 

Tasks 

1. Requirements 
determination and 
allocation 

System 

Control 

Trajectories 

Propulsion 

Structures 

Thermal 

Natural environment 

1. Acquire allocated requirements and constraints from system 
and interact, formally and informally, through allocation process. 

2. Obtain definition of configuration. 

3. Establish procedures, criteria, and approaches. 

4. Setup discipline specific criteria as the metrics for decision gates. 

5. Communicate through formal and informal integration process. 

2. Aerodynamic design 

System 

Control 

Trajectories 

Propulsion 

Structures 

Thermal 

Natural environment 

1. Develop aerodynamic models to determine force and moment 
coefficients and steady aero environments. 

2. Develop models to determine unsteady aerodynamic and heating 
environments. 

3. Establish all input data and determine aerodynamic design. 

- Provide aero parameter matrix and uncertainties. 

4. Communicate with interacting disciplines to resolve unacceptable 
conditions. Resolve informally if possible. 

5. Formally integrate aero attributes. 

6. Document attributes. 

3. Verification 

System 

Control 

Trajectories 

Propulsion 

Structures 

Thermal 

Natural environment 

1. Perform aerodynamic tests to verify force and moment 
coefficients and steady aero environments. 

2. Perform speciality tests to verify unsteady aerodynamic 
and heating environments. 

3. Update all input data and refine aerodynamic design data base 
using test data. 

- Refine aero parameter matrix and uncertainties. 

4. Communicate with interacting disciplines to resolve 
unacceptable conditions. Resolve informally if possible. 

5. Formally integrate aero attributes. 

6. Update documented attributes. 

7. Validate aerodynamic design data base during developmental 
flight tests. 


4. 3. 3. 3. 2 Task 2 — Aerodynamic Design. The aerodynamic design is accomplished by the 
aerodesigner with continuous formal and informal technical integration interactions with the appropriate 
groups as shown in table 3. Initially, all of the steady, unsteady, and heating aerodynamic parameters and 
their uncertainties are determined empirically from databases. Usually the estimates of all these quantities 
are conservative. As the configuration converges, more accurate determinations of the parameters are 
achieved via mathematical/numerical modeling and wind tunnel testing. The formal and informal 
technical integration continues in order to ensure that the aerodynamic attributes do not cause conflict or 
adversely affect the attributes of the other design functions. All unacceptable conditions are required to be 
resolved. After resolution is achieved, the aerodynamic attributes are formally integrated with the system 
design function. Finally, the significant aerodynamic features and the aerodynamic attributes are 
documented. 
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4.3.3.33 Task 3 — Verification. In order to ensure that all requirements and constraints are 
addressed, the verification activity is achieved with full cognizance of the appropriate groups as shown in 
table 3. Tests of the final (flight) configuration are accomplished to validate the already published 
aerodynamic parameters and determine the uncertainty associated with those parameters. Tests are also 
accomplished to determine parameters that are questionable and where the associated uncertainty is 
unknown. 

After all testing is completed, the aerodynamic attributes (i.e., parameter matrix and associated 
uncertainties) are reassessed and refined. Then those results are informally integrated with the appropriate 
design functions. Subsequently, the results are formally submitted to the systems design function for final 
assessments and documentation. If there is conflict, it must be resolved at the system level. This could 
lead to a redesign or to an operational constraint. When all of the aforementioned is completed, the 
aerodynamic design database is augmented with all the newly acquired configuration dependent data. 

The final validation is achieved during the developmental flight-test phase of the program. The 
flight-test data are compared to the aerodynamic attributes that are documented by the systems design 
function. If serious differences occur, there must be a redesign or an operational constraint must be enforced. 

The tasks delineated in table 2 from reference 2 correspond to the discipline specific tasks 
associated with the aerodynamic design function. A comparison to table 3 indicates that the tasks are 
complementary. It can be seen from table 3 that the emphasis is associated with allocation of requirements, 
aerodynamic design, and verification; and these are design function specific activities. 
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TRAJECTORY/G&N 




Figure 38. Design process technical integration — trajectory/G&N design functions. 

4.3.4 Trajectory/G&N Design Functions 

The connection between the design process technical integration and the trajectory/G&N design 
functions are delineated in figure 38. The illustration depicts the relationship between the trajectory/G&N 
design functions and the other subsystem design functions. In addition, it shows the work/information flow 
processes that are supported by key trajectory/G&N decision gates that are required to develop and assess 
the trajectory/G&N attributes. The details of all the above are delineated in this section. 

4.3.4.1 Trajectory/G&N Design Function Plane. The trajectory/G&N disciplines closely 
interact, and their design functions are shown together in figure 39. Trajectory design in this description 
encompasses payload performance and includes the design activity that determines what basic vehicle 
mass and propulsion characteristics are needed to achieve the desired pounds to orbit. The fundamental 
performance requirements are payloads to specified orbital targets to which are added vehicle constraints 
such as limits on acceleration, loads, thermal, dynamic pressure (flutter), etc. The additional complication 
of abort targets, separation targets, or reentry/recovery targets must be included as intermediate points on 
the trajectory if the system requires them. An initial definition is made of the trajectory and guidance 
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approach, and the philosophy and pertinent parameters, including their uncertainties, are identified. 
Trajectory optimization programs are used to determine trajectories that optimize the appropriate objective 
function and constraints. Initially, this is done deterministically with simplified models to establish basic 
feasibility, then with increasing fidelity, incorporating appropriate parameter uncertainties. Moment 
balance constraints are included for asymmetrical configurations. In early conceptual design, trajectory 
determination uses simplified representations of propulsion, aerodynamics, mass, winds, and air density. 


Informal 

Integration? 



Figure 39. Trajectory/G&N design function plane. 

Achieving desired payload to orbit with adequate performance reserves usually requires iteration 
of vehicle parameters with the system. The trajectory definition, constraints, and system parameters are 
iterated until the attributes are satisfactory. As the vehicle design process proceeds, trajectory design 
follows the successive refinement approach experienced by the other design functions and subsystems. 
It uses improved definitions of the vehicle and environment models to define trajectories (time histories of 
flight mechanics variables), performance, and performance reserves to higher fidelity. Both nominal 
trajectories and dispersed design trajectories are developed; the latter represent time-consistent trajectories 
that produce maximum expected values of certain variables such as loads or aerodynamic heating. 
Analysis using dispersions also produces performance sensitivities (partial derivatives), flight performance 
reserves, and fuel bias definition. 
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The performance and trajectories process flow diagram and WBS task chart from reference 2 are repro- 
duced in figure 40 and table 4, respectively. The process flow is consistent with the flow diagram of figure 39, 
with the former emphasizing inputs/outputs and connectivity, and the latter emphasizing the iterative compari- 
son of requirements and attributes to achieve convergence. Outputs are indicated for payload performance and 
trajectory time histories, both nominal and dispersed. The NxN diagram of reference 2 (Appendix A) is repre- 
sentative of further delineation of the inputs and outputs associated with the performance and trajectories design 
function process. The tasks given on the WBS chart are expanded in more detail in section 4.3.4.3. 



Figure 40. WBS 2.2 — performance and trajectories design process flow diagram. 2 


The G&N system design follows a pattern more similar to other design functions in that a tentative 
G&N configuration is hypothesized and then analyzed to determine its performance. In specifying sensor 
and algorithm requirements, close coordination is maintained with avionics specialists to obtain adequate 
performance at acceptable cost and complexity. Uncertainties (errors) determined from the analysis are fed 
back to the trajectory analysis as inputs to margin and reserve determination. The tentative G&N system is 
iterated until its attributes satisfactorily meet requirements, or else requirements relief is sought from the 
system plane. G&N system analysis and design activities shown in figure 39 are combined with the control 
system activities in reference 2. The G&N process flow and WBS from reference 2, therefore, are included 
in the figures in section 4.3.5. 1 . 
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Table 4. WBS 2.2 — vehicle performance and trajectories task description. 2 


Inputs 

Tasks 

Outputs 

•Mission definitions 
•Initial performance 
•Vehicle coordination system 
•Launch pad geometry 
•Project ground rules and goals 
•Redundancy requests 
•Preliminary design concept 
and database 
•Range safety constraints 
•Atmospheric model 
•Ascent wind models 
•Launch pad environments 
•Engine alignment tolerances 
•••Vehicle geometn/ drawing 
•Vehicle ascent aerodynamics 
•Heating indicators 
••Vehicle/stage entry aerodynamics 
•Engine inlet flow field definition 
•Engine installed thrust throughout 
trajectory 

•Qa, Qp constraints and structural 
load indicators 
-Wall/surface temperatures 
•Heating rate or temperature 
indicators 

•Autopilot definition 
•Guidance system inputs 
•••Modified autopilot to reflect 
a control law for airflow to inlet 
•Control surface mixing logic 
•Control weights and current weights 

3.2.1 Perform trade studies on trajectory/ 
configuration options 

3.2.2 Develop nominal trajectories 

3.2.3 Develop design trajectories 

3.2.4 Assess vehicle sizing, mass properties 

3.2.5 Evaluate vehicle performance 

3.2.6 Develop abort scenarios and trajectories 

•Staging requirements 
•Propellant requirements 
•Number of engines 
•Performance updates 
•Entry propellant weight 
•Ascent trajectory sets (altitude, 
velocity, X, p histories) and engine 
operating conditions 
•♦Entry trajectories 
•♦•Airflow history to inlet 
•Trajectory constraints 
•••Mach transitions 
•Loads trajectory data 
•••Ascent, cruise, loading requirements 
•Reference trajectories and time 
histories 
•Max Q 
•••a, airflow 

•••Ascent, cruise, landing requirements 
•Propellant load versus time 
•Burn times 

•Residuals at main engine cutoff, etc. 
•Vehicle mass versus time 
•l sp (flow rates) 

•Usable propellant requirements 
■Flow rates 
•System dispersions 
•••a inlet 

•••Derived air volume 

•Antenna range data 

•Launch mission rules 

•Vehicle breakup and disposal analysis 

•Launch commit criteria 

•Launch corridor 

•••Landing corridor 

•Abort alternate mission analyses 

•Event timelines 

Tools: 

• Software— Dynamic simulations, program to optimize 
simulated trajectories (POST) 


Key: • ELV, RLV, and RBCC 

~ RLV and RBCC 
— RBCC only 


4.3.4.2 Trajectory Gates. Trajectory design is driven by top-level payload performance and 
targeting requirements, along with constraints which limit the acceptable trajectories to those satisfying 
assumed system limitations such as staging conditions, maximum dynamic pressure, maximum load or 
thermal indicators, abort targets, etc. Working with appropriate other disciplines, the trajectory designer 
identifies pertinent parameters and their uncertainties and produces optimal constrained trajectories, both 
nominal and dispersed, to identify the distributions of trajectory performance variables. The trajectory 
designers work closely with specialists from structures/mass properties, aerodynamics, and propulsion, 
especially in the early design stages to iterate the basic variables of the vehicle in order to attain perfor- 
mance requirements with acceptable margins, considering parameter variations. Trajectory decision gates 
are shown in figure 41. Indicated gates consider three possibilities: (1) Surplus performance margin 
(unlikely), where the system plane is provided the excess margin for other tradeoffs; (2) neither surplus nor 
shortfall, where performance, sensitivities, and timelines are provided to the system plane without further 
iteration;and (3) performance shortfall. In the third case, collaboration with the above design functions 
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attempts to find an achievable fix for the problem within the respective requirements and constraints. If 
successful, an output like the second case is made, but, if unsuccessful, the issue goes to the system plane 
for relief or rebalance of requirements and constraints. 
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Figure 41, Trajectory design function gates. 
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4.3.4.3 Trajectory Tasks. The trajectory/performance design function is a part of the earliest 
conceptual feasibility activities. It iteratively matures its output through the design process and continues 
to perform mission-specific trajectory/performance determination in the operational phase. The primary 
responsibility is to determine the trajectory time histories that maximize payload performance subject to all 
pertinent constraints and to identify payload performance and margins, flight performance reserves, and 
fuel bias. The multiplicity of constraints on a typical launch vehicle that evolve concurrently with and as a 
part of design make trajectory design a highly interactive and iterative process. Task summaries are shown 
in table 5. 

4.3.4.3.1 Task 1 — Requirements Determination and Preliminary Performance Estimates. In the 
early part of conceptual design, the trajectory design function (referred to as “trajectory’ ) is a central 
element of concept feasibility screening. Working as part of a small group, trajectory obtains the vehicle 
fundamental concept, operating philosophy (e.g., abort accommodation), top-level payload requirements, 
and constraints from the system plane. Initial estimates of weight, drag, thrust, I sp , and any special environ- 
mental conditions are obtained from their respective design functions and disciplines. Using historical 
information, or by discussion with other disciplines, preliminary constraints are generated. Then, using 


74 




Table 5. Primary tasks for trajectory design functions. 


Activities 


Interactions 


1. Requirements determination 
and preliminary performance 
estimates 


System 

Mass properties 
Propulsion 
Aerodynamics 
Natural environment 


1 . 

2 . 


3. 


4. 


5. 


Tasks 


Obtain fundamental concept, operating philosophy (e.g., abort 
accommodation), and top-level payload requirement 
and constraints from system. 

Obtain initial weight estimate, drag estimate, thrust and l sp 
estimates, and any special environmental input from the 
respective design functions. 

Run simplified trajectory program with initial inputs to obtain 
performance (including appropriate margins). 

If desired performance not obtained, work with small group 
of representatives of other design functions to trade basic system 
descriptors (listed in item 2) to converge to a solution acceptable 
to all parties. 

If trades are major, or if convergence cannot be attained, 
take trade information to system for decision or requirement/ 
constraint change. 


2. Detailed payload 
performance determination 


System 

Mass properties 
Propulsion 
Aerodynamics 
Thermal 

Natural environment 


1. As concept matures, perform detailed trajectory simulation 
and payload determination, maintaining close coordination with 
pertinent other design functions. 

2. Although information is more detailed and interaction somewhat 
more formal than activity 1 , interact with other design functions 
on sensitivity and trade data to converge to acceptable solutions. 

3. Interface with system to provide sensitivity, trade, and margin 
information for possible adjustments to requirements, constraints, 


and allocations. 


3. Design reference 
trajectories 


Aerodynamics 

Thermal 

Structures (loads) 
Natural environment 


1. Obtain from thermal and loads disciplines indicator functions 
of trajectory variables, and calculate indicator values with each 
trajectory run within the trajectory/system/environment 
parameter space. 

2. Work with each respective discipline to select its design reference 
trajectory from the total set, representing a time-consistent 
trajectory which maximizes the appropriate indicator. Provide 
these to the disciplines as analysis simplification tools. 

3. Continue to consult with the disciplines as the design matures 
to make any necessary adjustments to the design reference 
trajectories. 


4. Verification 


System 
Aerodynamics 
Natural environment 
Propulsion 
Structures 


1. Develop high-fidelity simulation to accommodate test-verified 
models. 

2. Obtain test-verified models of major contributors to trajectory/ 
performance, such as propulsion system characteristics, 
structural mass, etc. 

3. Using this simulation, verify trajectory design over range 
of expected parameters and conditions. 

4. Obtain final verification from flight test. 


these initial inputs with a quick turnaround program, estimated payload performance and margins are 
determined. If desired performance is not obtained, the trajectory design function works with other design 
functions and disciplines to trade basic system descriptors (the inputs listed above) to converge to a solu- 
tion acceptable to all parties. If the trades are major or if convergence cannot be attained, trade information 
is provided to the system plane for screening decisions or revision to requirements/constraints. 
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4. 3. 4. 3. 2 Task 2 — Detailed Payload Performance Determination. Similarly to other design 
functions, trajectory accommodates increasingly detailed descriptions of vehicle and environmental 
parameters as the design progresses. The vehicle and environmental models include nominal and dispersed 
(uncertainty) parameters obtained from the propulsion, structures, and aerodynamics planes, and from the 
natural environment group. 

Likewise, performance requirements and system constraints are refined. The constraints which are 
imposed on trajectory shaping and engine throttling derive from numerous other disciplines and include — 


• State vector orbital targets 

• Intermediate staging states dictated by clearance, recovery, and disposal of stages 

• Structural loads (represented by load indicators) 

• Maximum dynamic pressure 

• Maximum acceleration 

• Aerosurface hinge moment limits 

• Aeroheating (represented by thermal indicators) 

• Abort targets and limits, if pertinent 

• Communication and range safety constraints 

• Etc. 

Trajectory identifies and updates these constraints through interaction with the other respective 
design functions and disciplines. 

Detailed trajectory optimization programs are used to determine trajectory and throttling time 
histories, payload performance, and flight performance reserves/fuel bias to accommodate variations in 
vehicle and environmental parameters. Sensitivity data are derived to guide trade studies and point the 
direction of design improvement. Informal trades are made among the design functions and disciplines to 
converge to acceptable solutions. The trajectory plane interfaces with the system plane to provide 
sensitivity, trade, and margin information for possible adjustments to requirements, constraints, and 
allocations. 

A cycle is complete when trajectories, dispersions, and margins meeting requirements have been 
determined for a comprehensive set of constraints and vehicle/environmental parameter values with 
variations. Validity and appropriateness of the input data, constraint definition, and program fidelity should 
be queried and brought to satisfaction. 

4.3.43.3 Task 3 — Design Reference Trajectories. Design reference trajectories are generated as a 
means of simplifying the loads and thermal analysis/design process. Since it is impractical to include all 
statistically-varying parameters independently in loads and thermal analysis, it is useful to develop refer- 
ence trajectories that represent the trajectory parameter set which maximizes (to a statistical measure) 
loads or aeroheating. These design reference trajectories then serve as nonlinear time-consistent bases for 
detailed loads or thermal analyses (usually linearized) that include the remaining larger set of additional 
parameter variations. 
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Trajectory obtains from the loads and aerothermal disciplines indicator functions of trajectory 
variables and calculates indicator values with each trajectory' run within the trajectory/system/environment 
parameter space. Trajectory then works with each respective discipline to select its design reference trajectory 
from the total set to a suitable statistical measure. This provides the loads and aerothermal disciplines a 
time-consistent basis upon which to develop their maximum design cases, considering the large set of 
remaining variables. Although this approximate approach is used as an expedient for analysis, lull-dimensional 
Monte Carlo check cases run in past programs have confirmed that the approximate approach achieved the 
desired statistical measure for the systems checked. As the design matures, trajectory continues to consult 
with the disciplines to make any updates or adjustments necessary to the design reference trajectories. 

4.3.43.4 Task 4 — Verification. Verification of the trajectory and performance design is accom- 
plished with high-fidelity analytical simulations that make use of test-verified models of key components. 
For example, propulsion system characteristics derived from hot-fire testing and actual structural weights 
are used in the verification simulation where possible. The vehicle and its environment are modeled in as 
complete detail as practical. The combined simulation then is used to verify satisfactory trajectory design 
over the range of expected conditions and parameter variations. Flight test provides the final verification 
and performance capability. 

43.4.4 G&N System Gates. In this document, the G&N design function is taken to be the G&N 
system design synthesis function, as distinct from the hardware/software design function which is assumed 
to be part of the avionics design function. G&N decision gates are illustrated in figure 42. Primary G&N 
system interfaces in the design process are with the trajectories, control, and avionics planes. (The avionics 
interface is for negotiating and specifying sensor and software requirements). G&N also works initially 
with the system plane to identify the requirements and philosophy which will be allocated from the system 
plane. Top-level requirements and philosophy as flowed down from the system plane are expanded with 
greater detail by the G&N specialists to provide the basis and starting point for G&N design. The design 
process involves the typical synthesize/analyze cycle. Outputs are the G&N system specifications, 
including algorithms and software requirements, sensor requirements, and operational information require- 
ments; i.e., what mission-specific information will have to be loaded. Before providing the converged 
outputs, the design must meet the gates of acceptable performance (accuracy, payload delivered), accom- 
modation of required failure and abort modes, and reasonableness of the requirements for sensors, 
software, and operational information. Close interaction with avionics specialists helps converge and 
assure the latter requirements are met. 
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4.3A5 G&N Tasks. Tasks for G&N are summarized in table 6. G&N synthesis requires interaction 
with the systems, trajectory, avionics, and control planes. 

4 . 3 . 4 . 5.1 Task 1 — Requirements Accommodation. G&N works closely with trajectory in deter- 
mining target accuracy and payload performance margin requirements and capability. The potential target 
errors of the G&N system are provided to trajectory as part of the dispersion set that determines perfor- 
mance reserve margins. Stringent accuracy assumptions in this margin drive the G&N system cost and 
complexity. G&N synthesis balances these conditions to converge on the best design. 

Constraints on the vehicle have a major effect on G&N design. For vehicles that require abort 
capability, abort modes are strong drivers. G&N works with the system and trajectory design functions to 
accommodate failure and abort modes. A constraint on maximum dynamic pressure may require throttling 
control that adapts to the specific state conditions. Constraints on the permitted range of engine throttling 
must be observed. 

Another balance that must be achieved is G&N system performance versus the complexity of 
operational data loads and updates needed to attain the performance for the range of expected missions. 
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Table 6. Primary tasks for G&N function. 


Activities 

Interactions 

Tasks 

1. Requirements 
accommodation 

Trajectory system 

t . Work with trajectory in converging to accuracy and payload 
margin requirements and capability 

2. Work with system and trajectory in accommodating constraints 
such as failure and abort modes, maximum dynamic pressure, etc. 

3. With system, determine appropriate balance between performance 
and complexity of operational data loads and updates. 

2. Detailed G&N system 
synthesis 

System 

Trajectory 

Control 

Avionics 

1 . Perform iterative synthesis/analysis to best balance performance 
requirements with cost and operational considerations. 

2. Maintain close coordination with system and trajectory as 
requirements mature, with control to define initiation state 
requirements and to coordinate flight control computer 
interactions, and avionics for software/hardware requirements 
(see below). 

3. Iterate to satisfaction of requirements and constraints with an 
adequate balance of performance and cost/complexity. 

3. Component and software 
requirements 

Avionics 

Trajectory 

System 

1 . Maintain close working relationship with avionics to keep abreast 
of hardware/software state of the art. 

2. During G&N system synthesis, work with avionics in 
specifying component and software requirements to 
provide acceptable performance, cost, complexity, reliability, 
operability, and maintainability. 

3. If performance cannot be achieved with hardware and software 
that meet avionics attribute allocations, explore performance 
requirement relief with trajectory and systems. 

4. If resolution not obtained, take to system for top-level trades. 

4. Verification 

Avionics 

Control 

Trajectory 

Propulsion 

System 

1. Develop high-fidelity analytical simulations, modeling system 
and environment. 

2. Using simulation, verify G&N performance over full range 
of parameter and environment variations. 

3. Work with avionics to perform software verify and validate (v&v) 
and to verify G&N performance in hardware/software test beds. 

4. Obtain final verification from flight test. 


43.4.5.2 Task 2 — Detailed G&N System Synthesis. The core activity of the G&N design function 
is to synthesize a G&N system architecture that best meets the vehicle requirements while satisfying inter- 
facing constraints. It is not the intent of this report to describe in detail the process used by G&N specialists 
to accomplish this, but to note primary considerations and interactions. 

The process is the usual iterative synthesis/analysis cycle, directed toward best balancing the 
performance requirements with cost and operational considerations. Throughout the process, close coordi- 
nation is required with the system and trajectory planes as described above, with the control plane to define 
guidance initiation state requirements and coordinate flight computer cycle requirements, and with the 
avionics plane for software/hardware requirements as noted below. 
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Where data and programs have been subjected to critical assessment, satisfaction of requirements 
and constraints and an adequate balance of performance and cost/complexity determine adequacy of the 
detailed design. 

4.3.4.53 Task 3 — Component and Software Requirements. One of the main outputs of the G&N 
design function is a converged set of requirements for G&N sensors and algorithm software which is 
provided to the avionics plane. Before and during the design process, G&N specialists maintain a close 
relationship with hardware and software specialists in avionics in order to keep abreast of the state of the 
art and capability. During system synthesis, G&N works very closely with avionics to specify component 
and software requirements which both meet system performance requirements and represent acceptable 
cost, complexity, reliability, operability, and maintainability. The latter set of requirements is captured in 
the system allocation of requirements to the avionics plane. 

If performance cannot be achieved with component hardware and software that meets the 
avionics plane allocations, G&N explores performance requirement relief with the trajectory design 
function. If resolution is not obtained, the issue is taken to the system plane for top-level trades or 
requirements revision. 

The process is complete when the sensor component and algorithm software requirements satisfy 
both the G&N system performance requirements (imposed on G&N) and the cost, reliability, operability, 
and maintainability requirements allocated to the avionics plane. 

43.4.5.4 Task A — Verification. Verification of the G&N system is accomplished primarily with 
analytical simulations, as augmented with the use of test beds involving flight-type hardware and software. 
High-fidelity analytical simulations are generated to model the G&N system along with the vehicle and its 
environment in as complete detail as practical. The combined simulation is run using the full range of 
expected parameter variations to ensure that satisfactory performance is attained at all operating conditions 
and system variations. Avionics test beds use flight-type hardware and software with simulated vehicle 
aspects to confirm the correct functioning of the G&N system as implemented physically (as discussed in 
the avionics section). Finally, flight test provides the final verification. 
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Figure 43. Design process technical integration — control design function. 


4.3.5 Control Design Function 

As shown in figure 43, the connection between the design process technical integration and the 
control design function is shown. The illustration depicts the relationship between the control design func- 
tion and the other subsystem design functions. In addition, it shows the work/information flow process that 
is supported by key control decision gates that are required to develop and assess the control attributes. The 
details of the above are delineated in this section. 

4.3.5.1 Control Design Function Plane. The control design function as represented on the control 
plane is illustrated in figure 44. The control design function involves the synthesis of the vehicle control 
system, specification of the control component requirements, and necessary interactions with other design 
functions and disciplines. Also involved is determination of vehicular dynamic response and the associated 
design parameters, including studies of lift-off and separation clearances, pogo, sloshing, etc. First, the 
requirements and constraints are interpreted into a form applicable to the control system. From experience, 
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a tentative control system configuration is defined, along with the philosophy, procedures, and criteria that 
will be employed. The control specialists then identify the matrix of parameters affecting the control 
system and together with specialists from other disciplines identify by data or judgment the variations 
(uncertainty distributions) of the parameters. Nominal and dispersed stability and response analyses are 
run to assess the performance of the tentative design. In some cases, such as structural loads, the accept- 
ability of the performance is determined initially by load indicators, but final acceptability of the refined 
design is determined on the structures plane. 


Informal . 


integration 



Figure 44. Control design function plane. 


Structural dynamics are shown on the diagram as a particularly significant input to the control 
analyses, but also other design functions and disciplines such as aerodynamics, trajectories, and propulsion 
are important interactors with control. A close relationship is necessary with the avionics and propulsion 
design functions that have the responsibility for the control system component hardware and software. The 
eventual specification of control system component requirements evolves from this close interaction and 
influences the cost, reliability, and operability attributes of the avionics and propulsion planes. Thus while 
response, stability, and margins are shown as the control system plane attributes, the attributes of control 
component cost, reliability, etc., on the avionics and propulsion planes are determined by the control 
component requirements as converged between the control system specialists and the avionics/propulsion 
specialists. The tentative control system design is iterated until its attributes meet the requirements and 
constraints, or relief from requirements is sought from the system plane. 
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In reference 2, the guidance and control functions are shown combined. The process flow diagram 
and WBS task chart from reference 2 are reproduced in figure 45 and table 7, respectively. The process 
flow is consistent with the flow diagram of the control plane, with the former emphasizing inputs/outputs 
and connectivity, and the latter emphasizing the iterative comparison of requirements and attributes to 
achieve convergence. The NxN diagram of reference 2 (app. A) is representative of further 
delineation of the inputs and outputs associated with the control design function. The tasks given on the 
WBS chart are expanded in more detail in section 4. 3.5.4. 

As will be addressed later, additional activities of the control design function are to specify design 
aspects necessary to ensure adequate lift-off and separation clearances, pogo stability, and propellant slosh 
stability. 
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Figure 45. WBS 2.6 — guidance and control design process flow diagram. 2 
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Table 7. WBS 3.6.0 — guidance and control task description. 2 


Inputs 

Tasks 

Outputs 

•Projected ground ruies 
•Design-to-cost goals 
•Launch probability requirements 
•Preliminary design concept 
and data base 
•Atmospheric model 
•Wind models (ground/ascent) 

•Gust models 
•Launch pad environments 
•Overall vehicle dimension 
•Engine alignment tolerance 
•Feedline drawings 
•Vehicle aerodynamics 
•Guidance and control instrumentation 
locations 

•Vehicle flex-body modes 
•Propellant slosh modes 
•Propellant feedline flex modes 
•Qa, Qp and structural load constraints 
•Mass properties control plan 
•Documented control weights 
•Weights, centers of gravity, moments 
of inertia 

•Mass versus time 
•Thrust vector control (TVC) gimbal 
capability (degree and rates) 

•Kinematic analysis 
•PU system definition 
•••Inlet airflow constraints for ascent, 
cruise, and landing 
•••Air capture transition 
•Sensor characteristics 
•Computational characteristics 
•Antenna types and locations 
•Hazard analysis 
•Fault tolerance requirements 
•Failure mode effects analysis inputs 
•••CIL inputs 

•Hardware design, development, testing, 
evaluation, and production costs 
•Cost trades 

3.7.1 Develop flight guidance and control system 
strategies 

3.7.2 Derive subsystem/component requirements 

3.7.3 Determine system performance/margins 

3.7.4 Determine induced environments 

•Maximum engine deflection 
•Control sensor locations 
•Control surface deflection requirements 
•Autopilot definition 
•Guidance system inputs 
•••Modified autopilot to reflect a 
control law for airflow to inlet 
•Control surface mixing logic 
•Slosh damping requirements 
•Qa versus Qp envelopes 
•Flex-body mode frequency constraints 
•Vehicle transient response to wind 
disturbances 

•Pogo suppressor requirements 
•TVC requirements 
•Reaction control system (RCS) 
requirements 
•Software requirements 
•Computer requirements 
•Sensor requirements 
•Power requirements for control 
system 

•Diagnostics/control logic 
•Technical descriptions 
•Test requirements to include 
instrumentation 
•Product quantities 
•Make or buy plan 

Tools: 

• General purpose simulations and control system 
analysis packages such as Matiab and Marshall 
Systems for Aerospace Simulation (MARSYAS) 


Key: • ELV, RLV, and RBCC 

*• RLV and RBCC 
•*• RBCC only 


4.3.5.2 Control System Gates. Decision gates for the control system design process are shown in 
figure 46. The control system synthesis process is accomplished by control systems specialists in concert 
with specialists from aerodynamics, structures, trajectory/G&N, avionics, and propulsion. Inputs to the 
process include the control philosophy and approach, allocated architecture (concepts and characteristics), 
and the expected environments. Stability analyses and response analyses are used to determine the perfor- 
mance of synthesized designs. Output of the process is the control system description, component and 
software requirements for the avionics group, control responses for the loads group and others, and attitude 
errors for the G&N group. Before a converged set of outputs are made, the control design must pass the 
gates of acceptable stability margins, sufficient control authority for maximum disturbances, acceptable 
load indicator ranges, acceptable attitude errors, operability and complexity appropriate to the system, and 
reasonable component and software requirements. Threshold levels for these gates are determined in 
collaboration with other disciplines as appropriate. The control design is iterated until the gates can be 
passed successfully, which is represented in summary on the control plane by the control attributes meeting 
the control requirements and constraints. 
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Pogo stability is assured by performing stability analyses of the engine/feedline/tank/structural 
system and specifying requirements for Pogo suppressors if needed to achieve adequate stability margins. 
Therefore, the Pogo gate (not specifically shown on the figure) is adequate Pogo stability margins. 

4.3.5.3 Separation System and Lift-off Clearance Gates. Separation and lift-off clearance analysis 
and design is an adjunct to control system design and extends to the design of the separation system or, for 
lift-off clearance, potentially to specification or modification of the launch pad interface (see fig. 47). 
Dynamic clearance analyses are conducted for tentative separation system designs with pertinent vehicle 
and environmental inputs. Appropriately, extreme disturbances and parameter variations must be incorpo- 
rated into the analyses. Separation system decision gates include adequate separation clearance margins 
and reasonable separation system component requirements at acceptable reliability and cost. When the 
design converges to meet these gates, the separation system specifications/drawings can be finalized. 

Lift-off clearance assurance is obtained through determining adequate lift-off clearance margins by 
dynamic clearance analysis. This analysis must include appropriately extreme disturbances and 
parameter uncertainties. Inadequate clearance margins require iterating on the independent variables, 
predominantly the launch pad interfaces. 
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Modify Control System A 

Figure 47. Separation system and clearance gates. 


4.3.5.4 Control Tasks. In this report, the control design function is taken to be the control system 
synthesis function, as distinct from the control hardware/software function which is assumed to be part of 
the avionics and propulsion design functions. It is assumed that the avionics design function has responsi- 
bility for sensors, computers, and software, and that the propulsion design function has responsibility for 
control effectors; i.e., actuators, reaction control systems (RCS) thrusters, and valving for differential throt- 
tling or secondary injection. As will be noted, a very close working relationship must be maintained 
between the control design function and these two hardware/software design functions in order to achieve 
a successful design. The main control activities in design are summarized in table 8 and are given below. 

4.3.5.4.1 Task 1 — Requirements Determination and Allocation. Requirements allocation is a joint 
responsibility between the system plane, the control plane, and the avionics and propulsion planes. Control 
and avionics/propulsion planes consult with the system plane in identifying and flowing down the initial 
requirements to which the control system must be designed. Avionics and propulsion are the design func- 
tions for the control system hardware/software and, therefore, are the keepers of the requirements for cost, 
reliability, maintainability, power usage, etc. Control is the control system design function and, therefore, is 
the keeper of the requirements for control system configuration and performance. Most of the top-level 
requirements that are allocated by the system plane fall in the former category (imposed on the avionics and 
propulsion planes), whereas the requirement imposed on the control plane is to deliver acceptable control 
performance for the vehicle. Acceptable control performance means acceptable stability, attitude errors, 
load responses, lift-off and separation clearances, etc. These are requirements that must be given definition 
by the control design function and are quantified by working interactively with the other design functions. 

As the design progresses, if the control system attributes do not meet the requirements and informal 
iteration among the design functions and disciplines cannot resolve the problem, the attributes and sensitivities 
are fed back to the systems plane for trades and possible revision of the requirements allocation. 
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Table 8. Primary tasks for control system design function. 


Activities 

Interactions 

Tasks 

1. Requirements 
determination and 
allocation 

System 

Avionics 

1 . Consult with system to aid in initial requirements allocation. 

2. Feed back attributes to system. Provide trade data 
and consultation for revised allocation if required. 

2. Control authority 

Trajectory 
Guidance 
Aerodynamics 
Propulsion 
Natural environment 
Structural 
configuration 
Avionics 
System 

1 . Determine wind, trajectory, and thrust disturbances with natural 
environments and propulsion. 

2. Consult with trajectory/guidance to determine acceptable 
response excursions. 

3. Consult with avionics/propulsion/structures to determine 
reasonable control effector authority limits or trades. 

4. For specified control concept and configuration, simulate with 
appropriate disturbance inputs to determine response 
excursions as functions of control authority. 

5. If response excursions and/or control authority are not 
acceptable, perform trades in concert with aerodynamics 
and configuration to improve conditions. Alternatively, revisit 
items 2 and 3 above. 

6. If issues resolved among participants, send attribute 
and configuration information to system. 

7. If issues not resolved, take to system for top-level tradeoffs. 

3. Detail control system 
syntheses 

System 

Trajectory 

Guidance 

Structures 

Propulsion 

Aerodynamics 

Avionics 

1 . Collect and derive requirements from system and interfacing 
design functions, along with internal design criteria. 

2. Perform iterative synthesis/analysis with increasing fidelity, 
directed toward meeting requirements, constraints, and criteria 
while balancing performance with cost and complexity 

3. Work informally with other design functions to resolve conflicting 
requirements. If resolution is not obtained, take to system 

for top-level trades. 

4. In addition to synthesized control system design, provide load 
indicator responses, providing load relief design if required. 

5. Interactively determine slosh baffle requirements. 

6. Using clearance analysis, determine separation system 
requirements and launch facility geometrical constraints. 

4. Component and software 
requirements 

Avionics 

Structures 

Trajectory/Guidance 

System 

1 . Maintain close working relationship with avionics to keep abreast 
of hardware/software state of the art. 

2. During control system syntheses, work with avionics in 
specifying component and software requirements, to provide 
acceptable performance, cost, complexity, reliability, operability, 
and maintainability, 

3. if performance cannot be achieved with hardware and software 
that meet avionics attribute allocations, explore performance 
requirement relief with structures (load indicators) and trajectory/ 
guidance (attitude errors). 

5. Verification 

Avionics 

G&N 

Propulsion 

System 

1. Develop high-fidelity analytical simulations. 

2. Using simulation, verify system performance over full range 
of parameter and environment variations. 

3. Work with avionics to perform software v&v and verify 
control performance in hardware/software test beds. 

4. Verify separation and clearance margins using high-fidelity 
response analysis, incorporating any available test-verified 
component models. 

5. Verify Pogo stability margins analytically, using test-anchored 
dynamic models of propulsion system and structure. 

6. Damping performance of the Pogo suppression system 
may be confirmed by pulsing during hot firing tests, 
with and without the suppressor. 



4.3.5A2 Task 2— Control Authority. An important early activity is sizing the control effectors for 
sufficient control authority. Effectors are the devices that cause force or torque to be applied to control the 
vehicle. Effectors may be engine gimbal actuators, aerodynamic control surfaces, engine differential throt- 
tling, etc. The range (or existence) of control capability in these effectors needs to be determined early in 
the cycle since it can have significant effects on the total design. Also, the rate capability of the effector is 
an important variable. 

Working with natural environments and the propulsion plane, control determines maximum wind, 
trajectory, and thrust disturbances and their appropriate statistical combination to provide a design distur- 
bance set. Vehicle mass and aerodynamics data are obtained from their respective disciplines, along with 
uncertainties in these parameters. (Note: Historically, problems have occurred in this area. Adequate 
definition of parameter uncertainties is critical.) Control consults with trajectory and guidance design func- 
tions to determine maximum response excursions acceptable to those functions. Control also works with 
hardware-responsible personnel from the propulsion design function and, in the case of aerodynamic 
surfaces, aerodynamics/structures design functions to obtain reasonable effector authority range and rate 
limits and the relationship of authority/rate values to hardware cost and complexity. (In very early design 
stages, control personnel may make preliminary control authority assessments based on their historical 
knowledge of the above variables.) 

A control system architecture is hypothesized and simulated with the above disturbances and 
parameter variations to determine response excursions as a function of control effector authority and rate. 
If response excursions and/or control effector authority/rate are not acceptable, trades are performed in 
concert with the aerodynamics, structures, and propulsion planes to improve the conditions. Alternatively, 
the response excursions and effector authority/rate definitions described above may be revisited. If issues 
are resolved informally among the participants, the control attribute and configuration information is sent 
to the system plane. If the issues are not resolved, they are taken to the system plane for top-level tradeoffs, 
reconfiguration, or requirements revision. 

When is the control authority determination adequately addressed? At each design cycle, there 
must be satisfactory definition of inputs, parameters, and their uncertainties. For example, aerodynamic 
data should have realistically sufficient uncertainties identified based on the data source (analytical, 
database, wind tunnel tests, etc.) The simulation model should be of appropriate fidelity, including allow- 
ances for response lags and unmodeled effects in the system. Margins or headroom should be provided, 
their magnitude being a function of the fidelity of the configuration definition and simulation. The margins 
will decrease as the design converges to better definition. For a given design cycle, control authority 
determination has been adequately addressed when effector authority/rate capabilities which are 
reasonable in terms of cost and complexity produce acceptable response excursions, while considering, 
and this is key, uncertainties and margins appropriate to the fidelity of the models. 

4.3.5. 4.3 Task 3 — Detailed Control System Synthesis. The core activity of the control plane is to 
synthesize a control system architecture that best meets the vehicle requirements while satisfying interfacing 
constraints. It is not the intent of this document to describe in detail the process used by control 
specialists to accomplish this, but to note primary considerations and interactions. 
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In addition to those requirements imposed by the system plane and those derived from interfacing 
design functions and disciplines, control uses informal design criteria (for example, phase and gain 
margins) which have the intent of assuring satisfactory stability and response. Input to the process includes 
the information noted in Task 2 from other design functions and disciplines, plus detailed sensor and 
actuator characteristics, structural dynamic modes, slosh dynamics, and engine dynamics. The process 
uses iterative synthesis/analysis with simulations of increasing fidelity as the design cycles progress. 

Typically, analyses and simulations are done on multiuse dynamics and control software (e.g., 
MARSYAS, Matlab, etc.) that accommodates a variety of system models. As the design progresses through 
finer definition, the model of the vehicle dynamics is expanded to include higher frequency structural 
modes and slosh modes. The model of the control system component dynamics is expanded to include 
higher order effects and nonlinearities. These models are used in stability and response analyses to assess 
the performance of the synthesized control system design. 

Wind disturbances may be represented in veiy early design stages by synthetic wind profiles that 
have been constructed to represent a high wind or design disturbance. Subsequently, sets of measured 
winds are used in Monte Carlo analyses to determine the system response in a probabilistic sense. 

Along with satisfying internal and external requirements and criteria, the control system design 
produces load indicator responses to disturbances and dispersions, configuring the system to provide load 
relief if necessary. Also, it interactively determines slosh baffle requirements and through clearance 
analyses determines separation system requirements and launch facility geometrical constraints. 

Again, adequacy of the detailed design is determined by satisfaction of requirements and adequate 
margins, where the input and simulation data and its uncertainties have been subjected to critical assessment. 

43.5.4.4 Task 4— Component and Software Requirements. One of the main outputs of the control 
plane is a converged set of requirements for control components and software that is provided to the 
avionics and propulsion planes. Before and during the design process, control specialists maintain a close 
relationship with hardware and software specialists in avionics and propulsion to keep abreast of the state of the 
art and capability. During control system synthesis, control works very closely with the avionics and propulsion 
planes to specify component and software requirements that both meet system performance requirements and 
represent acceptable cost, complexity, reliability, operability, and maintainability. The latter set of requirements 
is captured in the system plane allocation of requirements to the avionics and propulsion planes. 

If performance cannot be achieved with component hardware and software that meets the avionics 
and propulsion plane allocations, control explores performance requirement relief with the structures plane 
(load indicators) and the trajectory/guidance plane (attitude errors). If resolution is not obtained, the issue 
is taken to the system plane for top-level trades or requirements revision. 

The process is complete when the component and software requirements satisfy both the control 
system performance requirements (imposed on the control plane) and the cost, reliability, operability, and 
maintainability requirements allocated to the avionics and propulsion planes. Again, appropriate 
allowances for uncertainties and margins must be included. 
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43.5.4.5 Task 5— Verification. Verification of the control system is accomplished primarily with 
simulations of two types: (1) Analytical simulations and (2) test beds. High-fidelity analytical simulations 
are generated to model the control system and the vehicle/environment in as complete detail as practical. 
The combined simulation is run using the full range of expected parameter variations to ensure that 
satisfactory performance is attained at all operating conditions and system variations. Avionics test beds 
use flight-type hardware and software with simulated vehicle aspects to confirm the correct functioning of 
the control system as implemented physically, as discussed in the avionics section. 

Verification of lift-off and separation clearance is done in analytical simulations. Since this can 
only be done analytically, it is important that sufficient margins are maintained. Pogo stability verification 
also is done by analysis, using test-anchored dynamic models of the engine and structure. Pogo pulsing 
during engine hot-fire tests can be used to obtain engine dynamic response information and to show the 
damping effect of adding Pogo suppression systems. Sloshing and flexible-body stabilization are verified 
by the best-available analytical models but are not fully validated until flight. 
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STRUCTURES 




Figure 48. Design process technical integration — structure design function. 


4.3.6 Structures Design Function 

The connection between the design process technical integration and the structures design function 
is delineated in figure 48. The illustration depicts the relationship between the structures design function 
and the other design functions. In addition, it shows the work/information flow process that is supported by 
key structural decision gates that are required to develop and assess the structures attributes. The details of 
all the above are delineated in this section. 

The structures design function is defined as any design activity involving structural subsystems; 
e.g., tanks, interstages, thrust frames, lines, ducts, components, etc., and finally the total structural 
system (vehicle). 
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4.3.6. 1 Structures Design Function Plane. The structures plane in figure 49 shows the information 
flow among discipline functions required to accomplish the structures system design. The output of this 
plane is the structures’ design and its various attributes. The flow diagram starts with the requirements and 
the initial configuration, moves through the definition of philosophies, criteria, procedures, and approaches, 
then establishes the parameters and their uncertainties. The next blocks are the discipline functions which 
interact with the structural analysis to provide the structural design data. Included are the trajectory, controls, 
and thermal disciplines. Inputs to the discipline tasks are compatible data inputs from natural environments 
and materials. The structural analysis discipline functions are loads and response, stress, stability, buckling, 
etc. All these discipline functions culminate in the structural design discipline which produces the structural 
design. The discipline functions in conjunction with the design function are fundamental in defining the 
structural attributes. The integration of the tasks is performed using inputs and outputs from one discipline 
to the other, as discussed in the following sections. The tasks performed on the structures plane produce 
results which must be passed through a prescribed set of gates that determines when the design is completed. 
In cases where gates cannot be met, the structures plane communicates with the system plane to balance 
out the design. 

Informal^ 

Jnteg ration* 



Figure 49. Structure design function plane. 


As discussed previously, an NxN diagram has been developed consisting of a matrix of inputs and 
outputs (see ref. 2 and app. A). Table 9 depicts an exploded scale portion of this diagram, showing the 
inputs and outputs for structural analysis. Shown are the inputs from thermal and control. Structural analy- 
sis outputs are shown horizontally, and structural analysis inputs are shown vertically. For example, struc- 
tural analysis outputs are flex-body modes, propellant slosh modes, propellant feedline flex modes, and 
q-alpha and q-beta constraints as input to control, while control provides to structural analysis the inputs of 
slosh damping requirements, q-alpha and q-beta envelopes, flex-body mode frequency 
constraints, and autopilot definition. 
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Table 9. Example expansion of vehicle design NxN diagram. 2 


3.5 

Structural analysis 

• Temperature gradient 
design limits 

• Vehicle flex-body modes 

• Propellant slosh modes 

• Propellant feedline flex 
modes 

• Q*Alpha, CTBeta and 
structural constraints 

• Structural 
Temperatures/gradients 

3.6 

Thermal 


• Slosh damping requirements 

• Qxalpha versus qxBeta 
envelopes 

• Flex-body mode 
frequency constraints 

• Autopilot definition 

• Vehicle transient response 
to wind disturbances 


3.7 

Guidance and control 


4.3.6.2 Structures Gates. Structural decision gates are shown in figure 50. This figure shows the 
integration of structural assessment and structural design. The inputs are the prescribed concepts and 
characteristics. The basic outputs are drawings and specifications. Also shown are the corresponding gates 
that affect the structural design. For example, structural assurance must meet the criteria for stability, 
strength, endurance (fatigue and fracture), and reliability. The other gates are clear and left to the reader to 
interpret. Gate metrics that cannot be met result in either design change which meets the metrics or an 
involvement of the system plane to rebalance requirements, etc. 

The NxN diagram and related write-up separate structural analysis and structural design into 
separate activities while the structures plane is an integration of both. As a result, the NxN augments with 
more detail the activities of the structures plane. Figure 51 depicts the structural analysis process. The left 
side gives the requirements including the discipline criteria. One-way inputs and outputs are defined as 
well as the two-way inputs and outputs. The middle section of the chart shows the structural analysis tasks 
and the flow. The loads analysis is central to combining outputs from vibroacoustics and dynamic analysis. 
The loads output is input to the stress analysis which is then the input for the life or durability analysis. The 
products of structural analysis are shown on the right side of the chart. Other internal flows are shown 
including vehicle configuration, options, cost, etc. 


93 





TPS 

Accommodations 


Propulsion 

Accommodations 


c^ucUira! Desig 0 


Drawings 

and 

Specifications 


Operability 
• Accessibility 
A • Inspectibility 

< Y6S / y^ • Processing 
and Checkout 
; mi • Maintainability’ 

t Wo 7777777. 


Launch Facility I 
Accommodations! 


Structural 

Assessment 


Loads Thermal 


Structural 

Assurance 

• Stability Y 

• Strength 

•Endurance v' 

• Reliability No^ 


Manufacturing \ 


Prescribed 

Concepts 

and 

Characteristics 


Jnfeg ration 


Assembly 


Performance 
•Weight 
• Deflection 


Figure 50. Structure design function gates. 


Requirements i 

• Program Ground Rules 1 

• Factors of Safety Criteria j \ 

• Fracture Control Requirements! 

Inputs (One-Way) 

• Mass Properties 

• Natural Environments 

Outputs (One-Way) 

• Communication and Data 
Handling 

• Electrical Power 

tnputs/Outputs (Two-Way) 

• Vehicle Configuration 
and Structural Design 

• Performance and Trajectories 

• Aerodynamics and Induced 
Environments 

• Thermal 

• Materials 

• Guidance and Controls 

• Propulsion 

• Ground Operations 

• Safety 

• Reliability 

• Cost 


Internal Flow 

Consultation Options Trades Analysis Cost 

Vibroacoustic Analysis | 

• Random Vibration and Shock 
Criteria 

• Component Accelerations 
j (High Frequency, >5QHz) 


Load Analysis 

• Design Load 

• Vehicle Line Loads 
or FEM Loads 

• Component Accelerations 

• Load Spectra 

• Design Conditions 

- Ground Handling 

- Surface Transportation 

- Prelaunch, Flight 
Readiness Firing, Launch 

- Ascent, Staging 

- Reentry, Landing 

- Recovery 

Structural Dynamic Analysis 

• Transient Analysis 

• Structural Models and Modal 
Analyses 

• Propellant Slosh Dynamics 

• Flutter Assessment 

• Pre-Test and Post-Test 
Analyses tor Modal Survey 

• Stiffness Requirements 


Stress Analysis 

• Stress Analysis 

• Structural Sizing 

• Margins of Safety 

• Stresses and Strains 

• Deflections 

• Strength Verification 
Test Requirements 

SE d 

Life Analysis 

• Fracture and Fatigue 
Analysis 

• Cycles and Time to Failure 

• Proof Factors 

• Critical Initial Flaw Sizes 

• Nondestructive Test 
Inspection Requirements 


Products 

• Random Vibration 
and Shock Criteria 

• Design Loads 

• Structural Dynamic 
Analysis 

• Modal Survey Tests 
Analysis 

• Strength Verification 
Test Requirements 

• Stress Analysis 

• Fracture and Fatigue 


Figure 5 1 . WBS 2 . 4 — structures analysis design process flow diagram. 2 


94 




The structural design flow chart, figure 52, shows the structural design activity and has the same 
format as the structural analysis flow chart. Structural design deals with component geometry, interfaces, 
subsystem layout, etc. The major products are the design specifications and the drawings. 


Requirements 

• Program/Project 

• Concepts 

• Design 

• Verification 

• Constraints 


Inputs (One-Way) 

• Natural Environments 


Inputs/Outputs (Two-Way) 

• Performance and Trajectories 

• Materials 

• Manufacturing 

• Guidance and Controls 

• Mass Properties 

• Thermal 

• Structural Analysis 

• Propulsion 

• Aerodynamics and Induced 
Environments 

• Communication and Data 
Handling 

• Electrical Power 

• Ground Operations 

• Flight Operations 

• Safety 

• Reliability 

• Cost 


Internal Flow 


Consultation 

Options 

Trades 

Analysis 

Cost 


Vehicle Configuration 

• Subsystems 

• Interfaces 

• Moldline 

• Structural Element Function 


Structural Design 

• Component Geometry 

- Construction Type 

- Dimensions and Tolerances 

- Mass and CG 
-Cross-Section Properties 

• Interfaces 

- Mechanical 

- Datums 

• Subsystem Layout 
-Subsystem Placement 

- Line Routing 

- Access Panels 

- Vent Ductwork 

• Hoiddown/Release Mechanism 
-Staging 

- Active Systems 

- Passive Systems 





- 1 

i 

Hazards 

Benefits 

Reliability | Operability | Maintainability 


Cost/Make or 
Buy 

Resources 

Utilization 

Requirements 

Test 

Requirements 

S/W 

Algorithms 

Server 

Needs 

Materials/ 
Parts List 

Technical 

Descriptions 

Sizing/ 

Configuration 

Conceptual 

Sketches/Layouts 




L 

Products 

• Vehicle Configuration 

• System Layout 

• Construction Type 

• Detailed Drawings 

• Structural Mass 

• Subsystem Layout 

• Structural System 
Description 

• Functional Requirements 

• Vehicle/Pad Interface 

• Transportation 
Requirements 

• Verification Requirements 


Figure 52. WBS 2.1 — vehicle configuration and structural design process flow diagram. 2 


The NxN diagram is a complement to the structures plane, providing more details of tasks shown 
on the structures plane. The structures plane diagram shows the linkage between structural design, 
structural analysis, and the system plane. The tasks provided in reference 2 can be correlated to the task 
details given in section 4. 3. 6. 3 which follows. 
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Reference 2 delineates the WBS tasks with inputs and outputs as shown in tables 10 and 1 1. 


Table 10. WBS 2.4 — structural analysis task description. 2 


Inputs 

Tasks 

Outputs 

•Projected groundrules and goats 
•Factors of safety criteria and fracture 
control requirements 
•Launch platform finite element model 
•Ground and ascent wind models 
•Vehicle geometry 
•Vehicle/pad interface geometry 
•Holddown/release mechanism definition 
•Structural details 
•Component installations 
•Shock sources 

•External aerodynamic pressure 
distributions 

•Compartment pressures 
•Protuberance airloads 
•Acoustic/overpressure definition 
•Fluid dynamic loads (buffeting) 
•Structural temperature and gradients 
•Slosh damping requirements 
♦G-alpha, q-beta envelopes 
•Flex-body mode frequency constraints 
•Autopilot definition 
•Vehicle transient response to wind 
disturbances 

•Weights, centers of gravity moments 
of inertia 

•Ignition and shutdown thrust transients, 
timing 

•Steady state thrust oscillation 
•Ullage pressure and tank fill heights 
versus flight time 
•••RBCC exhaust/thrust 
•••Forebody inlet 
•Material properties 
•Material allowables 
•••Material selection consultation 
•••TPS design definitions 
•Material thermal (required/expected) 
•Drawings for flight GSE 
•Launch sequence timelines 
•Vehicle integrated OPS concept and 
requirements 
•FMR and LMR 
•Hazard analysis 
•Fault tolerance requirements 
•System and component reliability 
allocation and estimation 
•Failure mode effects analysis inputs 
•••CIL inputs 

3.5.1 Vibroacoustic analysis 

3.5.2 Load analysis 

3.5.3 Structural dynamic analysis 

3.5.4 Stress analysis 

3.5.5 Life analysis 

•Structural sizing, margins of safety 
•Loads and deflections 
•Propellant slosh baffle sizing 
•G-alpha, q-beta constraints and structural load 
indicators 

•Temperature gradient design limits 
•Vehicle flex-body modes 
•Propellant slosh modes 
•Propellant feedline flex modes 
•Q-alpha< q-beta and structural load constraints 
•Structural analysis of lines and brackets 
•Establish dynamic envelop of feedline 
•—Aft/forebody structures 
•• Life limit 

•Vibroacoustical design criteria 

•Review of battery cell design (pressure vessel) 

•Structural failure modes 

•Failure propagation logic development 

•Test requirements to include instrumentation 

Tools: 

• Commercial software — NASTRAN, ABAQUS, ANSYS, 
PATRAN 

• In-house software — dynamic loads analysis programs, 
NASGRO, bolt strength analysis software 

• In-house vibration data base 


Key: • ELV, RLV, and RBCC 

~ RLV and RBCC 
••• RBCC only 
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Table 1 1. WBS 2.1 — vehicle configuration and structural design task description. 2 


Inputs 

Tasks 

Outputs 

•Projected groundrules and goals 
•Production and ground OPS 
•Critical interfaces 
•Subsystems definitions 
•EPA and OSHA constraints 
•Environmental OPS constraints 
•Preliminary design concept and 
data bases 

•Staging requirements 
•Propellant requirements 
" Entry propellant weight 
•Pressure vent sizes and locations 
•Structural sizing and margins of safety 
•Loads and deflections 
•Propellant slosh baffle sizing 
•Cryogenic insulation sizing 
•Active thermal control system sizing 
•Temperature and propellant sensor 
locations 

•Maximum engine deflection 
•Control sensor locations 
•Control surface deflection requirements 
•Mass properties data— weight; 
e.g., inertias 
•Propellant inventory 
•Propulsion system layout 
•Tank internal pressures 
•••Forebody moldline (iterate required 
air volume) 

•••Staging requirements 
•••Propellant requirements 
•Material allowables 
•••Material selection consultation 
•••TPS design, thermal materials 
required 

•Packaging volumes required 
•Electrical power system (EPS) 
component details 
•Access requirements 
•••Turnaround, launch, and landing 
facilities 

•Vehicle integrated OPS concept and 
requirements 
•On-orbit flight OPS 
" Landing gear drawings 
•Fabrication parameters 
•Range safety requirements 
•Hazard analysis 
•Fault tolerance requirements 
•Reliability estimates 
•Failure mode effects analysis inputs 
"•CIL inputs 

•System-to-subsystem reliability, allocations 
Hardware design, development, testing, 
evaluation, and production costs 
•Cost trades 

3.1.1 Configure vehicle 

3.1 .2 Layout 3D structural model 

3.1 .3 Determine suitable construction type (e.g., 
truss, isogrid, etc.) 

3.1 .4 Select appropriate material 

3.1.5 Calculate structural member sizes 

3.1 .6 Analyze crosssection moments of inertia 

3.1 .7 Determine structural component mass and CG 
location 

3.1.8 Assess provisions for clearance and access 

3.1.9 Locate subsystems 

3.1.10 Route subsystem lines 

3.1.1 1 Produce detail drawing for manufacturing shop 

3.1.12 Design structural components 

3.1.13 Identify shock sources 

3.1.14 Specify critical dimensions 

3.1.15 Establish suitable manufacturing tolerances 

•Engine alignment tolerances 
•Vehicle geometry and structural details 
•Feedline drawings 
•Component weight estimates 
•Parts list 

•Cross-sectional properties 
•Line routing zones 
•Pressurant bottle locations 
•"Preliminary air column 
•"Profile 

• Power return thru structure 
•Component installation 
•Verification requirements 
•Transportation requirements 
•System definition and design 
description document 
•Holddown release mechanism 
•Hazard analysis inputs 
•Schematics 

•Failure mode effects analysis inputs 
"•CIL inputs 
•Technical descriptions 
•Test requirements to include 
instrumentation 
•Production quantities 
•Make or buy plan inputs 

Tools: 

• Commercial software — CAD platform and translators, 
EMS 

• In-house software— optimization design codes 


Key: • ELV, RLV, and RBCC 

- RLV and RBCC 
RBCC only 
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Table 12. Primary tasks for structures design function. 


Activities 

Interactions 

Tasks 

1. Requirements 
determination and 
allocation 

Mass properties 

System 

Control 

Trajectories 

Materials 

Propulsion 

Aerodynamics 

1 . Consult with system to obtain operations philosophy, 
constraints, cost, mass fraction, etc. 

2. Obtain initial configuration definition. 

3. Provide to systems the discipline peculiar criteria for formal/legal 
application. 

4. Develop discipline specific verification requirements. 

5. Setup allocated requirements, discipline specific criteria, etc., into 
the metrics for decision gates. 

6. Flow up derived requirements to system. 

2. Loads analysis 

Trajectory 

Control 

Aerodynamics 

Materials 

Thermal 

Propulsion 

Avionics 

Propulsion 

1. Setup describing equations (models) of the system (separate sets 
are required for the various mission events such as transportation, 
liftoff, max "g," max "q," separation, etc.). 

2. Develop all input data, configurations, environment, etc., and 
execute loads analysis. 

3. Work with trajectory, control, etc., to resolve excessive load 
conditions. Resolve informally, if possible. 

4. Consult system to resolve remaining loads issues, constructing 
derived requirements such as load relief controls. 

5. Input loads to stress and design. 

6. Work with propulsion, aerodynamics, and avionics to 
accommodate packaging and special requirements in the 
design. Continue to work trades and balancing activities. 

7. Insure that cost, reliability, and operations are a part of the 
design trades and metrics. 

3. Structural 
capability 
determination 

Loads 

Thermal 

Materials 

Aerodynamics 

1 . Determine strength margins, fatigue margins, fracture control 
requirements, and structural stability margins. 

2. Coordinate with design and loads to informally resolve 
undesirable margins. 

3. Consult systems for trades and requirements changes to resolve 
remaining margin issues. 

4. Continue to work with design to resolve issues and concerns 
through design changes. 

4. Structural design 

Loads 

Thermal 

Materials 

Stress 

1. Using system requirements, loads, thermal, and stress perform 
detail design, outputting configurations (geometry), materials, 
specifications, drawings, etc., to serve as baseline of next iteration 

2. Continue to work with stress, thermal, and systems to upgrade 
design to accommodate requirements change, reduced margins, 
and issues. Provide trade date and recommendations to 
program on issues. 

5. Verification 

Testing 

Loads 

Thermal 

Stress 

1 . Work with stress, loads, and thermal to determine test facility 
requirements, test condition, instrumentation, and data system 
requirements. 

2. Work between disciplines to evaluate results. 

3. Flowup anomalies to system for design changes or changes in 
operational constraints and procedures. 

4. Final structural validation achieved in development flight tests. 
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Structural analysis and structural design are shown separately, whereas these activities are 
integrated herein. 

4.3.6.3 Tasks. The top-level tasks of the structures plane are shown in table 12. They are divided 
into five categories: (1) Requirements determination and allocation, (2) loads analysis, (3) structural capability 
determination, (4) structural design, and (5) verification. For each category the interactions are shown 
along with the corresponding tasks. 

4.3.6.3.1 Task 1 — Requirements Determination and Allocation. Task 1 is a joint task between the 
system plane and the structures plane. The system goal is to take the total system level requirements, 
compartmentalize them, and allocate them to the planes. In this case, typical requirements allocated to the 
structures plane are: 

• Weight 

• Geometry constraints 

• Cost 

• Operations constraints 

• Schedule. 

The structures design function works with the system design function to properly accomplish this 
allocation task. 


The discipline groups develop a second set of requirements that are technical criteria. These are 
approved and levied by the project and controlled or managed by the disciplines. Typically in structures 
there is a detailed set of these criteria, documented officially by NASA for general use as legal require- 
ments. Generally, the criteria are too comprehensive and must be tailored by the disciplines, the system, 
and the project. Typical examples are strength criteria, endurance criteria such as fatigue and fracture, 
criteria for loads analysis, vibroacoustics, and attachment methods. 

Included in these criteria are not only safety factors but also verification requirements such as static 
and dynamic test, qualification and acceptance criteria, parameter variation ranges, and traceability. Gates 
include not only meeting requirements given in the criteria documents but validation of models, data 
accuracy, etc. If the model is wrong, the accuracy of the input data is immaterial. Therefore, all models 
must be verified. 

Finally, during the design and development process, derived requirements will evolve and can 
become part of the legal requirements. Examples of derived requirements are requirements for load relief 
control, slosh baffles, day-of-launch wind biasing, launch constraints, etc. In each case the design must 
accommodate the new requirements. The total set of structures requirements (allocated requirements, 
derived requirements, and formal discipline criteria) becomes the gate acceptance criteria (metrics) that 
determine if the structural design is acceptable and complete. The specifications and design attributes from 
the structures design plane are provided to the system and other design function planes. Obviously, some of 
these specifications and attributes result in constraints for the other planes that place limitations on their 
application and interaction with the structures design. 
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4.3.63.2 Task 2 — Loads Analysis. Utilizing inputs from (1) configuration, (2) natural environ- 
ment, (3) aerodynamics, (4) materials, (5) thermal, (6) trajectory, (7) control, and (8) propulsion; the 
external load environments are determined. For efficiency and ease, the loads analyses are performed 
separately for the various mission events involving (1) transportation and handling, (2) lift-off, (3) max q, 
(4) max g, (5) separation and staging, (6) docking, (7) reentry, and (8) landing and recovery. These inputs 
are also addressed in the NxN diagram, process flow, and WBS charts. Tables 10 and 1 1 define the WBS 
tasks with inputs and outputs (products) which include the load analysis. Table 12 defines the total 
structural analysis tasks, including inputs and outputs, with the load analysis being one element. The tasks 
in these three tables are compatible. The other design activities are covered in the subsequent tasks. 
Structural models, both rigid body and dynamic, must be developed for each event, describing the plant 
characteristics. These models are then combined into appropriate system models with all the environmental 
inputs, constraints, etc., and a response analysis is run to determine the combined loads. These must be 
defined in some statistical or quantifiable manner accounting for variations and unknowns. These results 
along with other data become the input to the next task. 

During this process, if excessive loads exist, then the load specialist works informally with other 
disciplines in an attempt to resolve the issue. Can aerodynamics be altered? Are the variations of key 
parameters too conservative? Are the criteria too conservative? Can the wind model be changed? Are 
dynamic tunings creating a problem, requiring detuning? 

Occasionally, the issues cannot be resolved informally. In this case the issue is carried to the system 
plane where trades and balances are accomplished across the subsystems, design functions, etc. For 
example, the configuration shape may be altered to change the aerodynamics. In order to reduce loads, yet 
maintain an acceptable system, criteria can be changed as well as design levels of parameter uncertainties 
and their combinations. 

Achieving the acceptable loads set requires that the loads specialists not only communicate and 
understand in depth their specialty, but that they have an understanding of the interacting disciplines. 
Together they must clearly define requirements for the needed input data. For example, they must specify 
the needed resolution of the aerodynamic coefficient matrix, pressure distribution spatial resolution, and 
critical locations requiring higher fidelity resolution. The interactions with other disciplines are very 
important and complex. They include but are not limited to the following: 

• Trajectories — definitions of the flight path and angles 

• Control — the control logic, control gains, and the dynamic responses 

• Interfaces — definition of mechanism envelopes, constraints required for separation, docking, etc. 

• Material — materials properties definition as a function of operational environments 

• Aerodynamics — definition of the aerodynamic and acoustic environments. 

The detail of the load process, technically and computationally, is not a part of this report. Other 
documentation (see bibliography) adequately covers those details. What is key here is an understanding of 
the metrics for deciding when the job is finished and how the models, data, etc., are validated. Uncertainty 
factors are normally used on loads until the model/data verification/validation are accomplished. This 
validation pertains also to both the stiffness and mass distribution of the models. 
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43.6.3.3 Task 3 — Structural Capability Determination. This task is concerned with determining 
the structural capability using the loads and other induced environmental inputs such as thermal. The 
capability assessments include at least the following: 

• Strength 

• Ductility 

• Fracture 

• Fatigue 

• Stability 

• Deflection/interference 

• Attachment capability (welds, fasteners, bonds, etc.) 

• Vibroacoustic capability. 

Very specific formal criteria are levied for each of these areas and must be met or a waiver 
approved. These criteria in general are the means of defining margins for the various predicted failure 
modes. If they are not met, then the same process, informal and formal, as discussed under loads is 
employed. There are four main interactions/interfaces for the stress functions: loads, thermal, materials, 
and facilities. The loads and thermal disciplines define the environments including accelerations, delta P’s, 
etc. The materials discipline defines the materials properties as a function of operational environments. 
Assembly and launch facilities define interfaces, constraints, etc. 

The activities on the structures plane require understanding load paths and stress variations and 
concentrations. As a result not only must the specialist understand the many various computerized tools 
such as finite element codes, thermal codes, grid codes, graphic codes, etc., but must be able to analyze by 
hand special cases of structural response and evaluate them with respect to criteria and specifications. 

The structural analysis function and the structural design function are highly interactive. There are, in 
general, two avenues open if the criteria are not met: (1) Change the design to accommodate the environments 
or (2) reduce the environments (loads) as discussed under loads. As a result, communications between loads, 
design, and stress are tightly knitted. Many problems can be solved informally among the three groups; 
however, some critical trades must be made through the systems plane due to the high complexity of the 
interactions which require tests and compromises. 

4.3.63.4 Task 4 — Structural Design. Structural design is one of the most complex tasks in devel- 
oping a launch vehicle. It requires strong interactions with all other disciplines, subsystems, etc., and the 
designer must be the structural design integrator. This dictates that the designer has not only an indepth 
understanding of design (load paths, functions, materials, attachments, etc.) but also an understanding of 
the supporting disciplines, subsystems, elements, etc. Parts standardization knowledge, as well as accepted 
design approaches, is also important. Materials selection is a key choice in design. All the margins are 
driven by materials selection, as is mass fraction, weight, etc. The structural design tasks are suboptimized 
tasks in that the design is driven by constraints and interface requirements as well as loads and thermal and 
many other tasks. As each design cycle is approached, the previous design cycle configuration is refined. 
In each new cycle, all problems raised in the previous cycle are accommodated or challenged on the 
systems plane against other requirements, criteria, and disciplines. In general the final decision must be 
approved at the system level. 
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Not only must the design tasks accommodate loads and thermal, but, also, they must accommodate 
design considerations of the following other factors: 

• Cost 

• Performance — mainly weight; structural efficiency 

• Operations — processing, check out, accommodation, accessibility 

• Propulsion — thrust frames and element location, lines, ducts, engines, etc. 

• Avionics — accommodation of electrical components, sensors, and actuator 

• Pyrotechnics — location and security 

• Manufacturing and assembly — design to accommodate and optimize 

• Launch facilities — interfaces, accessibility, etc. 

. XPS — structural design provides the support for the TPS 

• Packaging — structural design provides location and support for components, etc. 

• Materials — material characteristics required. 

The design process is further complicated by the wide choice of materials from composites to 
metallics; shapes, particularly shapes of tanks and fairings; stabilization techniques such as orthogrid, ring 
stringer, etc.; and manufacturing approaches such as welding, casting, powder metallurgy, etc. The wide 
choice of attachment approaches such as welding, rivets, adhesives, bolts, etc., is also a major 
consideration. Additionally, cost considerations greatly complicate the design process. All have impacts on 
structural margins and weights. 

The design is complete when all the decision gates are satisfied. Those gates include the top-level 
requirements, structural assurance, subsystems accommodations, and other significant design 
considerations as shown in figure 50. The top-level requirements are met with appropriate cost, weight, 
mass fraction, etc. The structural assurance is achieved when all the stability criteria and structural margins 
are satisfied. All subsystems and interfaces such as TPS, propulsion, avionics, and launch facility must be 
accommodated efficiently. Finally, the design must meet the gates of acceptable manufacturing, assembly, 
and operations. When all these gates are met, the drawings and specifications can be finalized. 

4.3. 6.3. 5 Task 5 — Verification. Verification of structural systems is one of the key tasks of assuring 
a launch vehicle is ready to fly. The verification process ensures first that the structures meet or exceed the 
requirements/specifications and, second, that the operational constraints/procedure are adequate to ensure 
structural integrity. The verification is a combination of analysis, similarity, and testing. Structural testing 
is the preferred approach; however, due to the cost of structural testing and the maturing fidelity of 
structural analysis, analysis is used in special cases in lieu of testing. Protoflight testing of structures is 
another viable option which incurs a small risk to flight hardware but validates the structure to loads 
slightly greater than limit. The missing link is quantification and understanding of critical failure mode 
margins. The philosophy of protoflight testing is “Test the hardware to a specific margin above the largest 
expected flight load (usually 5 percent), correlate the analytical model to that load, update the model, then 
use the updated model to predict margins.” Structural verification is, therefore, a combination of similarity, 
testing, and analysis. 
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a. Similarity. 

Verification by similarity is valid where a similar structure has been verified by test and the 
similarities can be quantified. In general, this technique is used when two or more of the same articles are 
built. In the case of components which must pass environmental testing at both the qualification/ 
verification level and acceptance level, only one article of a family (i.e., common valves) is qualification 
tested, thus qualifying the others by similarity. Acceptance tests, however, must be performed on all 
articles. These environmental tests include acoustic, vibration, and thermal. Since it is expensive and 
schedule critical, vibration environments (criteria that are acoustically driven) cannot always be verified 
by acoustic tests. Two techniques are used to verify these criteria: (1) Data bank scaling of similar 
structures that have been tested and (2) statistical energy analysis (SEA). 

b. Testing. 

As stated previously, testing is the preferred method of verifying the structure; however, cost and 
schedule many times prevents testing. Structural testing occurs at the part, component, subsystem, and 
system levels. Structural testing has several major categories: 

• Component qualification and acceptance (vibration, acoustics, thermal/vacuum) 

• Dynamics 

• Strength 

• Stability 

• Aeroelasticity (flutter, divergence, etc.) 

• Fatigue 

• Proof (fracture) 

• External loads 

• Pressure. 

Testing is accomplished to meet specifications, and traceability must be shown between the 
requirements and the test results. 

Coupon tests are conducted by the materials discipline establishing the materials characteristics in 
the following areas: 

• Ultimate strength 

• Yield strength 

• Fatigue life 

• Fracture 

• Environmental compatibility. 

Where required, these tests must include temperature and environmental effects. 

Component qualification and acceptance testing was discussed under similarity. 
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Dynamic tests are required to validate the dynamic model for control system design, Pogo suppres- 
sion, aeroelasticity, and loads. Models are corrected and updated based on the tests, then used by the above 
mentioned disciplines to perform their design and verification analysis. The test hardware must simulate or 
duplicate the dynamic characteristics of the system. Mass simulators can be used for components whose 
frequencies are outside the frequency range of the basic modes. Also, too many dynamically tuned or 
closely spaced component frequencies can contaminate the basic modal data, making it hard to get 
accurate data. Judgment must be used as to which are important. Sensitivity analysis helps quantity this 
judgment. Dynamic tests must consider boundary conditions, excitation methods and locations, 
instrumentation, modal goodness criteria, data collection, and evaluation systems. Testing boundary 
conditions in general are either fixed, fixed hinged, or free-free. Excitation methods are single-point 
random, multi-point random, sine sweep, sine dwell, and impulse. Model assurance criteria are used for 
mode selections from the test for modal correlation. These range from frequency accuracy to modal cross 
correlation, etc. Dynamic testing verifies the dynamic stiffness and mass distribution assumed by the 
analytical modeler. 


Strength verification applies the external loads environment, verifying the analytical model’s static 
stiffness assumptions and the critical load paths. If the structure is tested to failure, margins are verified 
along with critical failure modes. As discussed previously, if protoflight test is used, the structure is tested 
to limit load plus some margin below yield. The correlated/updated model is then used to predict margins. 


Aeroelastic testing establishes flutter margins. This is accomplished as an integrated structures/ 
aerodynamic wind tunnel test. The structures discipline must design the scaled wind tunnel model to have 
the appropriate scaled modal frequencies required to predict flutter. 

Proof testing takes advantage of fracture data, establishing that no flaws are present which will lead 
to failure in a prescribed mission lifetime. Proof pressure testing is used extensively for pressure vessels 
and rotating machinery. 

c. Analysis. 

Verification by analysis is becoming an acceptable approach in today’s environment. There are two 
basic approaches used for verification by analysis: (1) Models are benchmarked or correlated using tests 
(in particular protoflight test) and then used to predict structural failure modes and margins and (2) larger 
design safety factors are used to cover model uncertainties. Models/analysis also play a key role in test 
verification, predicting the test response, instrumentation utilization, loads application, etc. 

Structural verification uses the above three approaches (similarity, testing, and analysis), 
either independently or interdependently. Structural verification is complete when the requirements have 
been met. If requirements are not met, three options exist: (1) Redesign, (2) waive requirement, or 
(3) implement operational constraints and procedures. 
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THERMAL 



Figure 53. Design process technical integration — thermal design function. 


4.3.7 Thermal Design Function 

The connection between the design process technical integration and the thermal design function is 
delineated in figure 53. The illustration depicts the relationship between the thermal design function and 
the other design functions. In addition, it shows the work/information flow process that is 
supported by key thermal decision gates required to develop and assess the thermal attributes. The details 
of all the above are delineated in this section. 

The thermal design activity is fundamental to the vehicle design and its operational success. It 
consists of determining the thermal environments (with input from aerothermal), predicting the heat 
transfer, achieving the thermal designs, and providing verification. The thermal design activities provide 
design of insulation, TPS, and component and compartment TCS’s. These systems provide the desired 
thermal states for structures, propellants, components, payloads, and crew. An important function is 
providing structural temperatures for stress fields for fracture, fatigue, and deflection. 
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4.3.7. 1 Thermal Design Function Plane. The thermal design plane is shown in figure 54. It 
depicts the thermal design flow and various interacting discipline functions. The design process flow starts 
with requirements and the thermal system definition. Following these are the thermal system philosophies, 
procedures, and criteria. As in the other planes, the parameter matrix and uncertainties are developed by 
the discipline functions in conjunction with the system plane. The major discipline functions shown are 
heat transfer, thermal response, and thermal environments for such things as compartments and tanks. 
Outputs from these activities, as well as inputs from other disciplines, become the inputs for the TPS and 
TCS design. More details of the tasks are in later sections. The attributes of the thermal design are compared 
to requirements. If they meet the requirements, the design is complete; otherwise design iterations occur. If 
the design iterations cannot solve the problem, then the system plane becomes involved with trades and 
balances to achieve overall convergence. 

J Integration 


Informal 1 



Figure 54. Thermal design function plane. 


The thermal process flow from reference 2 is shown in figure 55. External inputs are shown as 
requirements, one-way inputs and outputs, and two-way inputs/outputs. These are the details of what is 
illustrated on the thermal design plane. The process flow represents the details of the discipline flow of the 
thermal design plane (shown as heat transfer, etc.). Depicted are the analysis tasks, thermal design data, 
and thermal design areas. The NxN diagram of reference 2 (Appendix A) is representative of further 
delineation of the inputs and outputs associated with the thermal design function. More detailed discussion 
is provided in the following paragraphs. 
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Requirements 

• Programs/Project 

• Concepts 

• Constraints 

• Designs 




Inputs (One-Way) 


• Natural Environments 


• Safety 


Outputs (One-Way) 


• Ground Operations 




Inputs/Outputs (Two-Way) 

• Performance and Trajectories 

• Aerodynamics and Induced 
Environments 

• Structural Analysis 

• Vehicle Configuration 
and Structural Design 

• Materials 

• Propulsion 

• Communications and Data 
Handling 

• Electrical Power 

• Mass Properties 

• Flight Operations 

• Cost 

• Reliability 


Internal Flow 



Consultation 

Options 

Trades 

Analysis 

Cosl 

Thermal Models/Analysis 

• Environments/Properties 
Data Base 

* Develop Modeis/Anaiyze 
-TPS 

- Cryogenic Tanks/Insulation 

- Main Propulsion System 
(MPS) Components/lnsulation 

- Structures 

- Compartment Conditioning 
-TCS (Active/Passive) 

- Integrated vehicle 



Thermal Design Data 

Material Selections 
Establish TPS Split Lines 
Establish TPS Thickness/Sizing | 
Establish Insulation Location/ 
Thickness/Sizing 
Determine Minimum/Maximum | 
Temperatures 
Determine Structural Gradients | 
Fluid Selection 
Heat Rejection Modes 
Special Components 
Overall Thermal Integration 
Thermal Interfacing Definition 
Establish Compartment 
Environments 


[Thermal Design 

TPS 

-Aerothermal 
-Base Heating 
-Control Surfaces/ 

Leading Edges 
Insulation 
-Tanks 

-MPS Components 
Structures 
Compartment Conditioning 
TCS (Active/Passive) 




Products 

• TPS Sizing 

• Cryogenic Insulation 
Sizing 

• Structure Temperatures/; 
Gradients 

• TCS Sizing 

• Compartment 
Environments 

• Thermal Design 


Figure 55. WBS 2.5 — thermal design process flow. 2 


4.3.7.2 Thermal Gates. The decision gates for the thermal design process are shown in figure 56. 
All these gates must be satisfied to produce the design of TPS, insulation, and TCS and to output structural 
temperatures and compartmental environments. 

The thermal design must pass not only the performance gates (margins and sensitivity) but also the 
discipline gates such as structural integrity. Thermal design is complicated in that it must protect from 
plume and aero heating, condition propellants (tank insulation), and provide thermal environments for 
components and crew. Interactions with other disciplines are a fundamental part of meeting the thermal 
gates. If the gates cannot be met through informal design interactions, the system plane is used to make 
trades and balance requirements. Foremost in the thermal gates is that the thermal model must be shown to 
have the accuracy required to predict thermal characteristics. Other gates include acceptable cost, 
reliability, and operability. 
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4.3.7.3 Tasks. The thermal WBS tasks from reference 2 are shown in table 13. These tasks delineate 
the discipline tasks depicted on the thermal design plane, figure 54. 

Shown in table 14 are the top-level thermal design function tasks including the activities, the inter- 
actions, and the tasks. This task matrix is provided to illustrate primary technical interacting activities 
discussed in the following paragraphs. 

4.3.7.3.1 Task 1 — Requirements Determination and Allocation. Task 1 is a joint activity with 
systems and other design functions to jointly define and allocate the systems and thermal requirements and 
criteria for thermal design application. As a part of this activity, a preliminary definition is made of the 
thermal system. Associated with this are the design philosophy, parameter definition, and uncertainties. 
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Table 13. WBS 2.5 — thermal design task description. 2 


Inputs 

Tasks 

Outputs 

•Projected groundrules 
•Design-to-cost goals 
•Preliminary design concept and data base 
•Launch pad environments 
•Configuration details, materials, 
dimensions 

—Ascent, cruise, loading requirements 
•Ascent aeroheating histories 
•Entry aeroheating histories 
•Compartment flow rates 
•Plume heating environments 
•Temperature gradient design limits 
•Mass properties control plan 
•Documented control weights 
•Weights, centers of gravity, moments 
of inertia 

•Ground hold conditions 
•Heat load requirements for propellant 
conditioning 

•Chill down requirements 
•Engine configuration 
•Engine operating characteristics 
•Engine thermal requirements 
•Material thermal properties 
•Material allowables 

— Material selection consultation 

— TPS vehicle interface definition 

— Material thermal required 
•Thermal design limits 
•Sensor characteristics 
•EPS operational environment 

requirements 

•Vehicle integrated OPS concept 
and requirements 
•Hazard analysis 
•Fault tolerance requirements 
•Failure mode effects analysis inputs 

— CIL inputs 

•Hardware design, development, testing, 
evaluation, and production costs 
•Cost trades 

3.6.1 Review Phase A results 

3.6.2 Establish properties data base 

3.6.3 Analyze thermal design concepts 

- TPS 

- Cryogenic insulation 

- Compartment thermal assessment 

- TCS (active/passive) 

- MPS 

3.6.4 TPS sizing 

3.6.5 Cryogenic insulation sizing 

3.6.6 TCS sizing (active/passive) 

3.6.7 Compartment thermal environments 

3.6.8 MPS thermal sizing 

•Temperature sensor 
locations 

•* Wall/surface temperatures 
•Heating rate or temperature 
indicators 

•Heating constraints 
•• Wall/surface temperatures 
•Structural temperatures 
and gradients 

•TPS sizing (aerothermal/base 
heating) 

•Cryogenic insulation sizing 
•Active TCS sizing 
•Component weight estimates 
•Parts list 

•Propellant condition 
•Temperature time history 
•Pressure 

•Chilidown of engine 
•Temperature and heating loads 
•Structural temperature 
requirements 
•Thermal environment 
•Thermal environment for EPS 
•Power requirements for 
thermal control system 
•Structural temperature 
requirements 

•Subsystem definition and design 
description document 
•Environments and loads definition 
•Materials type 
•Technical descriptions 
•Test requirements to include 
instrumentation 
•Production quantities 
•Make or buy plan 

Tools: 

• Commercial software — SINDA and PATRAN 

• In-house software 


Key: • ELV, RLV, and RBCC 

- RLV and RBCC 
— RBCC only 


A3. 132 Task 2 — Thermal Analysis. Task 2 utilizes Task 1 requirements and preliminary definition 
in conjunction with the design reference trajectory and the predicted external thermal environments to calculate 
the heat transfer, thus the temperature of the structure. The task evolves into three distinct analysis areas: 

• Thermal environments considering radiation, convection, and conduction for the compartments 
and tanks, as well as human environments, payload conditioning, etc. 

• Heat transfer characteristics 

• Thermal response of the system to the thermal environment. 
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Table 14. Primary tasks for thermal design function. 


Activities 

Interactions 

Tasks 

1. Requirements 
determination and 
allocation 

Mass properties 

System 

Aerodynamics 

Propulsion 

Trajectories 

Structures 

1. Consult with system to obtain operations philosophy, constraints, 
cost, etc. 

2. Obtain definition of configuration. 

3. Provide to systems plane discipline peculiar criteria for formal/ 
legal application. 

4. Develop thermal verification requirements. 

5. Develop thermal requirements into gate matrices. 

6. Flow up derived requirements to system. 

2. Thermal analysis 

Aerodynamics 

Propulsion 

Structures 

Trajectories 

1 . Set up describing equations for each of the separate subsystems 
and mission events. 

2. Develop all input data and execute various thermal analysis. 

3. Work with interacting disciplines to resolve anomalies, etc. 

4. Consult with system to resolve remaining issues. 

5. Insure that cost, reliability, etc., are included in trades, etc. 

3. Thermal system design 


1. Using system requirements, thermal analysis results, etc., design 
the TPS outputting design specifications to serve as the baseline 
for the next design iterations or for verification. 

2. Using system requirements, thermal analysis results, etc., design 
the TCS outputting design specifications to serve on the 
baseline for the next iteration or for verification. 

4. Verification 

Test 

Trajectories 

Stress 

1 . Work with interacting disciplines to determine test facility 
requirements, test conditions, instrumentation, and data 
system requirements. 

2. Work between disciplines to accomplish verification test. 

3. Work between disciplines to evaluate results. 

4. Flow up anomalies for resolution and operational procedures 
definition. 

5. Final thermal verification achieved in development flights. 


These data become the inputs for thermal design of TPS, life support systems, payload 
conditioning, and compartments, and for structural design to account for thermal effects. Thermal effects 
on structure include stresses, deflections, and materials property changes. Execution of this task requires 
close communications with the trajectory, materials, structures, propulsion, avionics, and aerodynamic 
design functions. This interaction includes both input data and output data. For example, the propulsion 
system may use a regenerative-cooled nozzle or an ablative nozzle where each requires special analysis. 
The regenerative-nozzle analysis includes flow circuits, boundary layers, film coefficients, heat transfer, 
etc. The ablative nozzle analysis combines heat transfer, gas dynamics, pyrolosis, materials, erosion, etc., 
to determine thermal/materials characteristics. 
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4.3.7.33 Task 3 — Thermal System Design. This task is responsible for the design of the various 
thermal systems. These designs include at least the following: 

• TPS and insulation for propellant conditioning 

• TPS for aerodynamic and plume heating 

• Life support thermal environment system 

• Payload conditioning 

• Ablative nozzles 

• Regenerative and passively cooled nozzles 

• Solid rocket motor insulation and heat protection 

• Compartment and component thermal conditioning (includes avionics components). 

Thermal design interfaces with the other design functions and with systems. These exchanges are 
both formal and informal. As the design evolves, the gates for completion are a combination of the perfor- 
mance and the specialist’s criteria. For example, structural margins for strength, fracture, and fatigue 
(influenced by temperature) must be met. The performance gates usually have to do with the resulting 
thermal environments and/or materials limits. Cost and operability are additional gates. Special gates exist 
for the special systems such as life support and ablative nozzles. The system, the design function, and the 
disciplines determine these special gates. 

Usually, thermal gates are worked informally with the various disciplines. If the informal approach 
cannot achieve an adequate design, then the system design function must provide the appropriate balance 
to achieve the best design. Engineering judgment plays a central role in the balancing act. 

4.3.73.4 Task 4 — Verification. Thermal verification generally is achieved using tests. These tests 
are for both components and subsystems. The tests are designed to duplicate the environments. As a result 
many thermal verification tasks must be accomplished in thermal vacuum chambers. Other tests include 
wind tunnel and hot-gas facility testing for aeroheating and propulsion plume impingement and solid rocket 
motor hot-fire test beds for solid rocket motor (SRM) components. 

Designing and conducting high-fidelity ground component and subsystem tests are essential to the 
verification process. Proper boundary conditions and environments must be ensured. All tests as with all 
models are approximations; therefore, the test limitations must be well understood and challenged. 
Verification, therefore, requires the following: 

• Environments definition 

• Component definition 

• Test constraints and fixtures 

• Instrumentation and data systems requirements 

• Test conduction 

• Test data evaluation 

• Correlation of analysis to test data. 

The verification of the thermal design is achieved when the analysis and hardware test data meet 
the requirements. Final verification can only be accomplished during developmental flight testing. It is 
very important that the development flights have proper instrumentation and data systems. 
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PROPULSION 



Figure 57. Design process technical integration — propulsion design function. 


4.3.8 Propulsion Design Function 

The connection between the design process technical integration and the propulsion design 
function is delineated in figure 57. The illustration depicts the relationship between the propulsion design 
function and the other design functions. In addition, it shows the work/information flow process which is 
supported by key propulsion decision gates that are required to develop and assess the propulsion 
attributes. The details of all the above are delineated in this section. 
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(Note: Design of the propulsion subsystem is a complex process in itself, involving numerous 
subsystems and specialties. This report does not describe the propulsion design process in detail but 
provides a top-level overview to show its relationship and interaction with the total vehicle design using a 
liquid engine system as an example.) 

The design of the propulsion system is strongly coupled with the structural design as well as the 
flight mechanics (trajectory, control response, etc.). The interrelationship between these design areas is 
very complex. Vehicle design can be characterized as putting a given payload into a specific orbit by 
achieving minimum dry weight with a highly efficient propulsion system. The propulsion system converts 
chemical, etc., energy into thrust, pushing the vehicle and payload into the desired orbit. Choice of the 
energy conversion system (liquid engine, solids, etc.) and energy source clearly has a strong influence on 
the structural system. Coupled together, they determine the flight mechanics system. Vehicle design from 
the performance standpoint is, therefore, concerned with three focus areas: (1) Structural (dry mass) 
efficiency, (2) propulsion system efficiency, and (3) management of losses (nonideal effects). 

4.3.8.1 Propulsion Design Function Plane. The top-level propulsion system (for a liquid engine 
example) design function is illustrated in figure 58. This figure shows as separate activities the design of 
the engine subsystems and/or elements. These are turbomachinery, combustion devices, lines, ducts, valves, 
ignition system, and the engine system. Each of these propulsion subsystems requires its own design 
including all of the interactions of the supporting discipline functions. The propulsion design process would 
be comparable to the design process presented in this report. This top-level chart is provided because of the 
strong interaction between the propulsion system and the rest of the launch vehicle. 
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Figure 58. Propulsion design function plane. 
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This strong interaction results in many trades and balancing of the attributes of the propulsion 
system and the other design functions of the vehicle such as trajectory, structures, and control. These 
design functions are heavily involved also in the system trades which balance requirements and perfor- 
mance attributes. For example, there may be a trade between the amount of payload to orbit and the size of 
the propulsion and structural systems, with the associated cost. 

The process starts, as it has for each of the other planes, with requirements definition and 
allocation, then proceeds to the parameter matrix definition, then to design the system, subsystems, etc. 
Section 4.3.1 discusses this generic process. 

Figure 59 from reference 2 shows the inputs, outputs, requirements, and products, as well as a 
limited process flow. The process flow only shows the activities supporting structural design and trajectory 
design. The detail designs of the propulsion system and its subsystems are not shown; however, they are 
required to generate the data for the activities shown. It is assumed that these complex activities are 
accomplished in designing the propulsion system. The propulsion system entry on the NxN diagram from 
reference 2 (app. A) follows the same pattern shown previously. 


Requirements 

• Program/Project 

• Constraints 

• Concepts 



Inputs/Outputs (Two-Way) 

• Vehicle Configuration 
and Structural Design 
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• Aerodynamics and Induced 
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• Structural Analysis 

• Thermal 
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• Flight Operations 

• Manufacturing 

• Safety 

• Reliability 

• Cost 

Mm mmmmJ BU Sm 



Internal Flow 


Consultation 

Options 

Trades 

Analysis 

Cost 


Feed System Geometry 

• Tank/Feed System Analysis 

• Tank/Feed Fluids 

• Pressure Analysis 

• Schematic Drawings 
-Lines 

-Ducts 

-Valves 

-Components 


• Propellant Inventory 


IT ^T 

Hazards 

Benefits 

Reliability | Operability | Maintainability 

Cost/Make or 
Buy 

Resources 

Utilization 

Requirements Test S/W Server 

Feedback Requirements Algorithms Needs 

Materials/ 
Parts List 

Technical Sizing/ Conceptual 

Descriptions Configuration Sketches/Layouts 


Products | 

• Design and Layouts f 

• Weights, Parts List 

• M PS/Engine System I 

• Propellant Inventory 

• Ullage Requirements | 

• Lox/Fuei Feed Geometry j 

• Net Positive Suction I 

Pressure (NPSP), 
Pressure Drop j 

• Propellant Conditions 1 

• Fluid, Thermal, Pressure | 
Models 

♦FPR, Start/ 

Shutdown Transient f 


Figure 59. WBS 2.8 — propulsion system design process flow diagram. 2 
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4.3.8.2 Propulsion Gates. Figure 60 illustrates the propulsion system decision gates. The gates 
the propulsion system must meet include I sp , thrust, thrust to weight, and volumetric constraints, as well as 
the normal discipline gates associated with the discipline functions. Examples are control system stability, 
turbomachinery stability and vibration, thermal, structural strength, and durability, as well as other pertinent 
gates associated with propulsion system design. 



Figure 60. Propulsion design function gates. 


The propulsion decision gates include first and foremost the engine performance, which is its 
ability to efficiently convert chemical energy into propulsive energy (thrust) at the level required to meet 
the vehicle performance. Implied in this statement are the additional factors of weight, thrust to weight, 
volume, etc. The engine system must also meet cost, reliability, and operational requirements. In addition 
to these performance and program requirements, the propulsion system, its subsystems, elements, and 
components must meet all the discipline requirements such as strength, fracture, fatigue, thermal, etc. 
Additional thoughts on these gates are in section 4. 3. 6.2. The major point to remember is that there are 
many crucial trades between the propulsion system and the rest of the vehicle that result from attempting to 
meet their respective gates. It should be remembered that the propulsion system provides the energy to 
achieve orbit. In achieving this requirement, it dictates much of the structures design. For example, the 
liquid propellant tanks and lines transfer the chemical potential energy to the engines that produce thrust 
that transmits through thrust frames back to the tanks, etc., to achieve vehicle kinetic energy. Thus, the 
propulsion system greatly influences the dry weight (mass fraction) of the system. The vehicle cannot 
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weigh too much or it is too costly. Its geometry cannot be too expansive or, again, operations and cost 
are too high. Reusable systems also require well-defined, efficient, and effective maintenance and 
refurbishment characteristics. All these become part of the propulsion system gates and tasks. 

4.3.8.3. Propulsion Tasks. 

4.3.8.3.1 Task 1 — Requirements Determination and Allocation. The propulsion system WBS from 
reference 2, table 15, is limited to a set of tasks that interact with the other vehicle design functions. There 
are many tasks required to design the propulsion system and produce the inputs for the tasks defined in 
table 15. They include design of the engine system, turbomachinery, combustion devices, and engine 
components. The discussion in the following paragraphs will briefly discuss these tasks. At top level, 
technical integration tasks are shown in table 16. As with the other design planes, the charts show the 
general activities, the interactions, and the tasks. 

Propulsion system design, as all other design functions, starts with an interaction with the systems 
plane to determine and allocate requirements to the propulsion plane. Because the propulsion system is com- 
posed of many subsystems and elements, these top-level requirements must then be distributed and allocated 
to the propulsion subsystem levels; for example to turbomachinery and combustion devices. The subsystem 
requirements are modified by the engine concept selected; e.g., staged combustion versus a gas generator 
system. In addition, there is a strong interaction from the materials, manufacturing, and structure planes. 

In the discussion that is to follow, it is assumed that the propulsion system has been chosen and that 
the trades and sensitivity data generated to make the selection are available along with the preliminary 
configuration definition (i.e., staged combustion cycle, liquid hydrogen and oxygen propellants, etc.). This 
information, along with the above allocated requirements, starts the design process. 

Propulsion system design to some extent follows the same compartmentalization approach 
discussed previously. Subsystems include engine systems, line and ducts, valves, turbomachinery, 
combustion devices, nozzles, control, etc., each requiring its own design specialties. Key disciplines are 
rotordynamics, fluid dynamics, thermal, stress, dynamics, fatigue, fracture, combustion, etc. Not only 
must the propulsion system meet all its engine specific gates but must satisfy the vehicle-imposed 
requirements. Since the propulsion system ends up influencing a large percentage of the total structural 
system, this interface is very important. Propellant tanks, for example, compose a large volume and weight 
of the structure, carrying loads as well as propellant and conditioning the propellant in terms of at least 
temperature and pressure. Propellant utilization is an important part of the design (how, when, etc., the 
propellants are flowed and managed). This includes the provision for dumping propellant for aborts or 
removing propellants during extended holds. A major factor in vehicle design is accommodation (location 
and arrangement) of engines and the transfer of the energy (thrust) efficiently to provide vehicle 
acceleration. The first task of propulsion system design is, therefore, the requirement determination and 
allocation, first from the systems plane to propulsion plane, then from the propulsion plane to its various 
subsystems, etc. 
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Table 15. WBS 2.8 — propulsion task description. 2 


Inputs 

Tasks 

Outputs 

• Projected groundrules, design-to-cost 
goals 

•Technology requirements (TRL level) 

•Engine t/F 

•Redundancy requirements 

• Programmatic constraints 
•Launch pad environments 

•Vehicle configuration and tank geometry 

• Line routing zones 
•Pressurant bottle locations 
“•Preliminary air column 
•••Profile 

•Vehicle mass versus time 

•Thrust, acceleration and pressure versus time 

•l sp (flow rates) 

•Usable propellant requirements 
•Axial acceleration 
•Dynamic pressures 
•Flow rates 
•System dispersions 
•Wind dispersions 
“• Air inlet constraints 
•••Derived air volume 
•Air loads on propulsion elements 
“ Engine installed thrust 
•^Forebody pressure recovery and flow 
field definition history 
•Structural analysis of lines and brackets 
•Establish dynamic envelop of feediine 

• Determine line thickness 
“•Aft/forebody structures 
•Propellant condition 
•Temperature time history 
•Pressure 

• Chilldown of engine 
•Temperatures and heating loads 
•Pogo suppressor requirements 
•TVA requirements 

•RCS requirements 
•Mass properties control plan 
•Weights, centers of gravity, moments 
of inertia 

•Material compatibility 
•Contamination analysis 

• Material properties 

•Thermal and cryogenic properties 

•Temperature limits 

•Telemetry capability 

•Sensor characteristics 

•Availability of power (current, voltage, phase) 

•Operational timelines 

•Maintainability 

•GSE capability 

•Vehicle integrated OPS concept 
and requirements 
•Flight timeline 

• Fabrication parameters 

•Flight safety review of schematic and OPS 
•East and west test range interface 

• Hazard analysis 

•Fault tolerance requirements 
•Reliability allocation and estimation 
•Failure mode effects analysis inputs 
*“CIL inputs 

•Hardware DDT&E and production costs 
•Cost trades 

3.9.1 Establish baseline feed system geometry 

3.9.2 Analyze tank/feed system fluid, thermal issues 

- Temperature profiles 

- Cryo fluid management 

- Pressure drop, NPSP availability, water 
hammer 

- Residuals ullage 

- Propellant inventory 

3.9.3 Pressurization system sizing and design 

3.9.4 Valves, ducts, mechanisms design, and layout 
drawings 

3.9.5 TVC components and design 

3.9.6 Propulsion system schematics and layout 
drawings 

3.9.7 Testing engine/propuision component 

•Propellant inventory 
•Propulsion system layout 
•Tank pressures 

• Propellant level sensor locations 
•“Forebody moldline (Iterate req air volume) 
•“Staging requirements 

•“Propellant requirements 
“•Number of engines 
•“Performance updates 
“ Entry propellant weight 
•Propellant load 

•Engine performance (l sp , thrust) 
•“Expected engine mach transitions 
•“inlet captive volume 
•“Recovery pressures 
•“a, for inlet airflow as a function 
of mach number 
•“Mach transitions 
♦Engine dimensional and operational 
characteristics 
•Turbine exhaust definition 
•On-pad effluent definition 
•“RBCC exhaust conditions 
•“Forebody inlet performance requirements 

• Ignition and shutdown thrust transients 
and timing sequences 

•Steady state thrust oscillation 
•Ullage pressure and tank fill heights versus 
flight time 

•“RBCC exhaust/thrust 
•Ground hold conditions 
•Heat load requirements for propellant 
conditioning 

•Chill down requirements 

•Engine configuration 

•Engine operating characteristics 

•Engine thermal requirements 

•TVC gimbal capability (degree and rates) 

• Feediine layout 
•Kinematic analysis 
•PU system definition 
“•Air capture transition 

•Propulsion system drawings and models 

•Component weight estimates 

•Parts list 

•Life limits 

•Instrumentation 

•Uplink/downlink requirements 

• Drive electronics 
•Electrical power requirements 
•MPS checkout and fill 

• Refurbishment/inspection requirements 
•Verification requirements 
•Transportation requirements 
•Subsystem definition and design 

description document 
•Vehicle controls 

• Power usage 
•“Flight rules 
•Drawings and schematics 
•Hazard analysis inputs 
•Functional failure model 

•Failure propagation logic development 
•Diagnostics/control logic 
•Failure mode effects analysis inputs 
•“CIL inputs 
•Technical descriptions 

• Vendor quotes 

•Test requirements to include 
instrumentation 
•Production quantities 

• Make or buy plan 

Tools: 

• In-house software 

• Fluid flow models— cryo fluid management thermal 
models 

• Testing 

• Commercial software— CAD layout/drawing packages 


Key: • ELV, RLV, and RBCC 

- RLV and RBCC 
— RBCC only 



Table 16. Primary tasks for propulsion design function. 


Activities 

Interactions 

Tasks 

1. Requirements 
determination and 
allocation 

Systems 

Turbomachinery 

Combustion 

Valves, ducts 

Structures 

Thermal 

Flow 

Control 

Trajectory 

1. Work with systems to flowdown requirements to propulsion 
including thrust, i sp , T/W, geometry, tankage, etc. 

2. Work with propulsion subsystems to allocate requirements for 
design and verification. 

3. Provide to systems, discipline peculiar criteria for formal/legal 
applications. 

4. Develop verification requirements for systems as well as 
propulsion subsystems. 

5. Develop metric flowdown for use by design function gates. 

6. Flowup derived requirements to system. 

2. Engine system design 

Flow 

Thermal 

Combustion 

Turbomachinery 

Control 

Structures 

Testing 

1. Determine engine performance characteristics flowdown/allocate 
requirements to subsystems in conjunction with subsystem inputs. 

2. Develop propellants, usage requirements, and coordinate with 
structural airframe design. 

3. Establish propulsion systems development and verification 
ground-test and flight-test program in conjunction with systems 
plane, propulsion subsystems, and disciplines. 

3. Engine subsystem design 

Propulsion systems 

Materials 

Flow 

Thermal 

Manufacturing 

Testing 

1 . Design combustion devices to meet vehicle systems and engine 
systems requirements and discipline criteria. 

2. Design turbomachinery to meet vehicle systems and engine 
systems requirements and discipline criteria. 

3. Design lines, ducts, and valves to meet vehicle systems and 
engine systems requirements and discipline criteria. 

4. Develop ground test program/requirements for each subsystem. 

4. Verification 

Propulsion system 

Dynamics 

Stress 

Thermal 

Manufacturing 

Systems 

1. Develop facility (test stands) requirements and implement in 
conjunction with engine system, subsystems, and disciplines. 

2. Coordinate hotfire test requirements with engine systems and 
subsystems and disciplines including instrumentation, data 
systems, and test profiles. 

3. Run ground test program (hotfire) in conjunction with engine 
system, subsystem, and disciplines, obtaining and coordinating 
data for development, verification, and acceptance. 

4. Develop plans for qualification and acceptance gates with engine 
systems, subsystems, and disciplines for static and dynamic ground 
test that includes, at least, flow, modal, fatigue, strength, vibration, 
and thermal. 

5. Run ground test programs (static and dynamic) in conjunction 
with engine systems, subsystems, and disciplines obtaining and 
coordinating data for development, verification, and acceptance. 

6. Establish the constraints, maintenance, and operations procedures 
from results of test program. 

7. Final propulsion system validation is achieved in developmental 
flight tests. 
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4.3.83.2 Task 2 — Engine System Design. Task 2 takes these requirements/criteria and designs the 
propulsion system. This design process is very complex. Analytical models are difficult to obtain. As a 
result, during design and development of liquid propulsion systems it is mandatory that component and 
systems tests be used to evolve the design. They can range from air- and water-flow simulations to hot-fire 
component tests as the design evolves. Then, finally, propulsion systems are developed, verified, and 
accepted in single engine and propulsion system test stands. A major design activity becomes one of 
determining test profiles, evaluation metrics, acceptance metrics, etc. 

The engine system design must combine all of the subsystems/components into a working system. 
System design is very complex and challenging. How do you start the engine? How do you control flow 
and mixture ratio? How do you throttle and shut down the engine? A part of this sequence is engine 
conditioning before start due to the use of cryo propellants and engine conditioning and purging after 
shutdown. Obviously, part of this design is tying the valves, actuators, igniters, etc., together through a 
control system. The timing and balance between the propulsion subsystems, components, etc., is very 
critical to engine operations. Packaging is also a key issue since, in general, volume is a prime design 
constraint. As a result, the engine system must put all the parts together and ensure that they work. 
Managing losses such as flow losses is very critical. Matching the propulsion system to the vehicle system 
is mandatory. Therefore, interaction between the vehicle system and the propulsion system determines the 
propellant capacity required, flow rate, and pressures to the vehicle system (then structures), as well as the 
thrust, etc., and derived requirements such as pogo suppression. Thrust and I sp are provided as propulsion 
attributes to the system and trajectory planes. Aerodynamics and thermal require the nozzle geometry, 
thrust, etc., to generate aerodynamics (mainly drag) and plume heating environments. Also, in general, the 
propulsion system provides thrust vectoring for vehicle controllability. 

It should be pointed out again that the propulsion system and the vehicle are strongly coupled. 
Eighty to ninety percent of the vehicle mass is propellant which drives the structural size. The propulsion 
system provides the power for boosting payloads to orbit. Producing the power causes effects on 
aerodynamics and vehicle drag. Usually engines are thrust vectored to provide control thrust as well as 
axial thrust, in addition to the large coupling with launch vehicle system performance. As a result, detailed 
communication is required between the propulsion system, the vehicle system, and the other design 
functions and subsystems. 

4.3.8.33 Task 3 — Engine Subsystem Design. The subsystem/component design usually proceeds 
in parallel. Turbomachinery must move the propellants at a certain flow rate and pressure. As a result the 
pumps are a high-energy system requiring a large power source to provide the energy to move the 
propellants. The first set of gates for turbomachinery design is, therefore, its performance in terms of flow 
rate and pressure. Designing this type of high performance machine introduces the potential for cavitation 
and other propellant instabilities that can destroy a pump or degrade its performance. These stability 
margins become a another set of gates. Rotordynamic stability is another design issue requiring not only 
damping devices but also minimizing the destabilizing forces. Excessive vibration prevention due to 
unbalance, etc., is another design task. Gates for rotordynamic stability margins and vibration levels are 
required. The turbine can have the same kind of issues including disk mode instability, flutter of turbine 
blades, etc., which must be prevented and require gates as well. Bearing wear is also a design issue. The 
gate on bearings can be a trade between lifetime and maintenance (bearing replacement). In addition to 
these very complex, dynamic, and thermal issues, the pump is also a pressure vessel (high pressure) and 
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must meet strength requirements. It also must meet durability requirements that include low- and 
high-cycle fatigue, fracture, flutter/vortex shedding, acoustics, and creep. The turbomachinery is, 
therefore, a very complex design problem with a very stringent set of gates from performance, to stability, 
to strength and durability. There are other gates which must be met, such as weight and cost; however, 
some trades to balance can be made between subsystems and at the engine systems plane, as well as at the 
vehicle systems plane. 

Combustion devices follow a similar breakout of design tasks and gates. The first task is the energy 
conversion task (combustion). Due to the shape of the chamber and other factors, combustion instability 
can occur, reducing efficiency or even destroying the engine. Gates exist for performance as well as 
stability. Thrust and I are the performance gates. Combustion instability is difficult to predict 
analytically, thus resorting to test. Combustion chambers and devices are subject to flow instabilities, 
strength, fatigue, and fracture. Large thermal gradients impact the low-cycle fatigue. Gates, usually the 
typical structure types, are necessary for these areas. All combustion processes create noise which also 
impacts the fatigue gates. The combustion device design is also complicated by ignition. 

Nozzles can be considered a part of combustion devices or a separate entity. They are very strongly 
coupled with the combustion devices and the overall performance of the system. Basically, the nozzle 
shape greatly influences the thrust of the engine. At sea level a low nozzle exit-area-to-throat-area ratio is 
needed to maintain throat stability as a function of power. At vacuum conditions, a large area ratio is 
required. Most engine nozzle design is a compromise between atmospheric and vacuum conditions, thus a 
restriction on the throttle (thrust) level is required in the atmosphere. During start up and shutdown, large 
shock transients are produced. These transients can produce fatigue damage to the nozzle. Nozzle cooling 
can be passive or regenerative. In the regenerative cooled case, care must be taken to control leakage, 
particularly if the engine bums hydrogen. Clearly the nozzle design must deal with strength, fracture, and 
fatigue. These issues are complicated by the large thermal gradients present. The nozzle design must meet 
weight, dynamic, and performance gates, as well as the typical strength, fracture, and fatigue gates. 

Valves, actuators, lines, ducts etc., all follow the same approach. Their design must meet the 
performance gates, as well as the standard structures and materials gates. Because of materials 
compatibility issues, especially with hydrogen and other exotic propellants, gates for materials 
compatibility exist for the design of all engine parts. Stress corrosion can be a problem for some parts. 

43.8.3.4 Task 4 — Verification. Verification of the propulsion system is very complex and costly, 
due first to the complexity of the fluid flow and chemical conversion systems (combustion devices). 
Second, the high performance requirements drive structural design, flow design, thermal design, etc., 
which usually require special verification. Verification is always a combination of analysis, simulation, 
and test. The tests consist of component and element tests and system hot-fire tests. Not including all the 
developmental tests, SSME required for certification at the engine system levels 20,000 seconds on each 
of two engines of hot-fire ground test. Each new engine or refurbished engine must pass a hot-fire ground 
acceptance test. The engines and hot-fire tests have special instrumentation for adequate evaluation. 
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In addition to these engine system tests, the following tests are performed on elements and components: 

• Cold flow (water and air) 

• Dynamic (model testing, spin-pit testing) 

• Proof pressure 

• Strength 

• Fatigue (low and high cycle) 

• Qualification and acceptance 

• Vibration 

• Thermal 

• Material characterization 

- Extreme hot and cold (near melting to cryo) 

- Environments (hydrogen embrittlement) 

- High mean loads. 

Key also is the use of simulations where the engine components and elements such as avionics/ 
control, valves, etc., are coupled with a computer simulation of the other functions such as the combustion 
process. This allows efficient verification of sequencing, coupling, and software. 

Analysis with test verified models is used in general to establish propulsion system structural 
margins such as strength. Many other analysis tasks include extrapolation to flight environments, 
off-nominal conditions, etc. There are many verifications which are combined test and analysis. These 
include propellant conditioning that leads to temperature and pressure requirements on tanks and lines, 
engine conditioning, start sequences, shutdown sequences, and purges. 

Verification of the propulsion system is, therefore, very complex as touched on here briefly. The 
complexity is greatly increased for high performance manned usage. In this case, reliability and safety is 
crucial, leading to the requirement for safe engine shutdowns and vehicle aborts. The final verification is 
achieved through developmental flight testing. 
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AVIONICS 



Figure 61. Design process technical integration — avionics design function. 


4.3.9 Avionics Design Function 

The connection between the design process technical integration and the avionics design function 
is delineated in figure 61. The illustration depicts the relationship between the avionics design function 
and the other subsystem design functions. In addition, it shows the work/information flow process that is 
supported by key avionics decision gates that are required to develop and assess the avionics attributes. 
The details of all the above are delineated in this section. (Note: Design of the avionics subsystem is a 
complex process in itself, involving numerous subsystems and specialties. This document does not 
describe the avionics design process in detail but provides a top-level overview to show its relationship 
and interaction with the total vehicle design process.) 

In this report, the avionics subsystem includes all vehicle electrical and electronic systems, such as 
GN&C, RF/communications, data management subsystem (DMS) including computers and engine 
controllers, instrumentation, software, electrical ground support equipment (EGSE), and the electrical 
power system. 
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4.3.9.1 Avionics Design Function Plane. The avionics design function includes responsibility for 
designing the electrical and electronic hardware and software that comprise the avionics system for the 
vehicle. The avionics system is often considered to be the flight system only. However, both the flight 
systems and the ground support and checkout systems are included here as part of the avionics design 
function. Subsystems of the avionics system include GN&C, DMS, RF/communications, instrumentation, 
software, EGSE, computers, and electrical power. Typical flight hardware components include the vehicle 
computer, the engine controller(s), the telemetry processor, multiplexers, data storage, antennas, transmitters, 
receivers, video cameras and processors, instrumentation, sensors, signal conditioners, batteries, cabling, 
power conditioners, power distributors, rate gyros, and actuator controls. The avionics design function 
plane is illustrated in figure 62. The avionics design function involves the synthesis of the avionics system 
to meet requirements in two general categories: (1) Performance of the electrical / electronic systems and 
(2) resource and interface requirements, including cost, reliability, weight, power use, volume, and thermal 
conditions. The design of the avionics system involves interactions with disciplines in other design functions 
including the systems plane. Interaction with the systems plane is vital in determining the requirements for 
the avionics system. The system plane establishes the aforementioned general categories of requirements. 
Internal to the avionics design function is the avionics system engineering and integration discipline. 
This discipline is responsible for understanding the requirements for avionics from the systems plane and 
deriving the more detailed avionics system requirements. Requirements are allocated and analyses and 
trade studies are performed. Reliability requirements are considered together with weight, power, volume, 
and cost to determine the appropriate level of redundancy and redundancy management which is a major 
driver in avionics complexity. From these requirements, the avionics system architecture is defined. All 
disciplines within the avionics design function are involved in the architecture definition, but the avionics 
systems discipline is responsible for assuring that the architecture will meet the overall requirements and 
constraints. Component requirements and constraints are derived and an electrical, electronic, and 
electromagnetic (EEE) parts plan is developed. 



Informal 7| 
Integration J 


Figure 62. Avionics design function plane. 
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An important factor at the time of the architecture definition is the determination of the means and 
extent of verification of the avionics system. In some cases, verification may begin in an avionics systems 
testbed or hardware simulation laboratory. Within the testbed, vehicle and engine computer simulations 
are integrated with the various hardware elements allowing early system testing of the avionics system. 
This testbed is also used for the important function of verification and validation of the vehicle flight 
avionics system software. Flexibility is built into the testbed so that all avionics hardware elements do not 
have to be present at all times. Those hardware elements not present are simulated with computers and 
software or, in some cases, simple electrical simulations. 


The defined architecture provides the basis for preliminary layouts of the various avionics 
elements. The preliminary layouts are determined from the judgment of the designers as to what hardware 
will best meet the requirements and the proper division of hardware and software functions. Analysis and, 
where appropriate, breadboard testing determine the performance and uncertainties of the components. 
Packaging to accommodate the environments is designed, and estimates are made of the power, weight, 
volume, and thermal characteristics. The collected attributes of the preliminary design are then compared 
with the avionics requirements and constraints, and the design is iterated until satisfactory convergence or 
relief from requirements is sought from the system plane. Make or buy decisions are made on the 
individual elements of the preliminary design. These elements are built and tested before integrating into 
the avionics subsystem. Testing as a system may be done in a hardware simulation laboratory. An overall 
representation of the avionics systems design process and the interactions is depicted in figure 63. 



Figure 63. Avionics systems design process interactions. 
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A listing of inputs and outputs for the avionics design function process along with discipline activi- 
ties and products is shown in figure 64. This process flow diagram addresses design considerations for the 
elements that comprise the total avionics system and is consistent with the flow diagram of the avionics 
plane. Table 17 is a WBS for the design process for a typical avionics subsystem, the DMS. The WBS 
chart lists specific tasks that are embedded in the task categories of section 4.3.9.3 and the inputs and 
outputs of the subsystem design process. The WBS for the other subsystems, including software, would be 
of a similar nature. Figure 64 and table 17 are an adaptation of the process flow diagrams and task WBS 
charts of reference 2. 
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Figure 64. Avionics process flow diagram. 


125 



Table 17. Data management subsystem task description. 


Inputs 

Tasks 

Outputs 

•Avionics system requirements 

• Avionics architecture 

• IP&CL 

• Natural and induced environments 
-Thermal 

-Vibration 
- Radiation 
-EMI 

• Materials 
•Weight 

• Power 
•Volume 
•Cost 

• Verification requirements 

• Manufacturing 

• Vehicle configuration 
•Flight operations 

• Ground operations 

• Safety 

• Reliability 

3.10.3.1 Requirements 

3.10.3.1.1 Components 

3.1 0.3.1 .2 Avionics system inputs 

3.10.3.2 Design 

3.1 0.3.2. 1 Trades and analysis 

3.10.3.2.2 Subsystem design 

3.10.3.2.3 Components 

3.10.3.3 Documentation 

3.10.3.3.1 Parts list 

3.10.3.3.2 Schematics 

3.10.3.3.3 Released drawings 
3.10.3.4 Test 

3.1 0.3. 4.1 Test requirements 

3.10.3.4.2 Test procedures 

3.10.3.4.3 Component tests 

3.10.3.4.4 Subsystem tests 

3.10.3.4.5 Test reports 

3.10.3.5 Subsystem/component GSE 

3.10.3.5.1 GSE trades and analysis 

3.10.3.5.2 GSE design 

3.10.3.5.3 GSE test 

3.10.3.5.4 GSE documentation 

3.10.3.6 Project/program reviews 

•Subsystem design specifications 

• Right components specifications 
-Computer 

-Command receivers 

- Data processors 

- Remote data acquisition units 

- Storage devices 

• GSE specifications 
-Subsystem design 
-Components 

• Released drawings 
-Test specifications and 

procedures 


The design and development of the avionics software and the EGSE should be an integral part of 
the avionics design function from the onset. The development of the software requirements requires the 
interactions of the other design functions through the systems plane. This is evident from consideration of 
examples of typical functions relegated to the software, such as execution of vehicle and engine control 
algorithms, receipt, interpretation, and execution initiation of uplinked commands, acquisition of data 
from on-board instrumentation, and compilation and formatting of instrumentation and operations data for 
telemetry downlink. Typically, the development of the detailed software requirements may lag the 
development of the hardware requirements. For example, it may be prudent for the completion and review 
of the software requirements to coincide with the review of the preliminary design of the avionics system. 
The EGSE requirements depend on the overall GSE requirements for the vehicle which is a responsibility 
of the system plane. Typically, there may be requirements for ground power systems and a ground computer 
system to control and monitor the vehicle ground checkout process. The design of these EGSE systems 
may be complex and require a process similar to the flight system design process. The ground computer 
system must have numerous hardware interfaces for meeting requirements for issuing command discrete 
and analog voltages and acquiring instrumentation data and the vehicle telemetry stream. A user interface 
system for the EGSE computer must be developed. In some cases, it may be cost effective and technically 
desirable to achieve some software design commonality in the EGSE computer system and the 
aforementioned hardware simulation laboratory, particularly in the user interface, the command handling, 
and the telemetry processing functions. 
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4.3.9.2 Avionics Gates. Decision gates for the avionics design process are shown in figure 65. 
Inputs to the process are the avionics philosophy and approach, the environments for the hardware, and 
performance requirements from the vehicle subsystems that require avionics, such as GN&C, propulsion, 
thermal, and structures. Interactions with these subsystem design functions are required throughout the 
design process. Gates for the avionics system fall into three general categories: (1) Performance gates 
which measure the functional performance of the various avionics subsystems against their requirements; 
(2) survivability gates which measure the ability of the avionics hardware to withstand its environments; 
and (3) resource/operational gates which measure attributes such as weight, power consumption, volume, 
thermal conditioning requirements, reliability, operability, and cost. Functional performance is determined 
by analysis, simulation, and breadboard, prototype, and qualification testing. Layout and packaging to 
withstand thermal and vibroacoustic environments lead to units which are environmentally tested, with the 
packaging design being modified until survivability is demonstrated. Avionics designers are guided by 
program requirements and resources. The top-level attributes such as cost, weight, power, volume, reliability, 
and operability are measured against allocated requirements. Once the design has converged to satisfy all 
gates, the avionics system drawings and specifications can be released, software produced, hardware 
manufactured, and avionics components and subsystems tested. 
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Figure 65. Avionics system design function gates. 
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4.3.9.3 Avionics Tasks. The top-level avionics design activities are summarized in table 18 and are 
described below. The design activities include both flight and ground support equipment. 


Table 18. Primary tasks for avionics design function. 


Activities 

interactions 

Tasks 

1. Requirements 
determination and 
allocation 

System 

Internal system groups 

Control 

G&N 

Propulsion 

Thermal 

Natural environments 

1 . Consult with system to aid in initial requirements allocation of 
cost, reliability operability, maintainability, etc. 

2. Consult with control, G&N, propulsion, and any internal system 
group to obtain avionics hardware/software/EGSE performance 
requirements. 

3. Obtain environmental requirements, both natural and induced. 

4. Feed back attributes to system and to system groups. Provide 
trade data and consultation for revised allocation, if required. 

2. Avionics architecture 

System 

Internal system groups 

Control 

G&N 

Propulsion 

1. Obtain requirements from system and other system groups that 
specify hardware/software requirements. 

2. Identify candidate architectures and component options for flight 
and ground. 

3. Determine redundancy concept. 

4. Identify initial make/buy approach. 

5. Perform initial top-level assessment of attributes and compare 
with requirements. 

6. Modify architecture as required and iterate requirements if needed 
to achieve convergence of attributes and requirements. 

3. Avionics subsystem 
design 

Internal system groups 

Control 

G&N 

Propulsion 

Thermal 

Structures 

Environments 

1. During detailed design, maintain close coordination with system 
groups that specify hardware/software requirements. 

2. For subsystems, including EGSE, and components that are to be 
made versus bought, perform necessary design steps through 
concept identification, analysis, breadboarding, component 
testing, and integrated testing. 

3. Develop necessary software from requirements through coding, 
checkout, and verification and validation testing. 

4. Iterate performance and requirements to obtain convergence. 

5. Track cost, reliability, operability, and maintainability attributes, 
iterating with system if not compliant with requirements. 

4. Verification 

Internal system groups 

Control 

G&N 

Propulsion 

Thermal 

Structures 

Environments 

1 . Establish a verification plan at early stage of design or 
procurement. 

2. Perform functional verification incrementally as components are 
developed. 

3. Perform qualification testing on flight components. 

4. Perform integrated testing of hardware components on integrated 
test beds. 

5. Perform verification in applied environments— vibrations, 
thermal, vacuum, EMI, radiation, etc. 


4.3.9.3.1 Task 1 — Requirements Determination and Allocation. This activity is a joint responsibility 
between the system design function and the avionics design function, working also with the design functions/ 
subsystems where avionics has responsibility for hardware/software design and implementation. These 
include all of the avionics subsystems and other appropriate interacting disciplines. As the hardware/software 
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design organization, the avionics design function is the keeper of the requirements for cost, reliability, 
maintainability, power usage, etc., as allocated from the system plane. Performance requirements for the 
avionics components are derived through interaction with the design functions that have the system design 
responsibility in their respective areas. For example, for control system sensors (i.e., rate gyros, 
accelerometers, etc.), the sensor range, sensitivity, resolution, bandwidth, and noise requirements are obtained 
from the control design function after close interaction between avionics and GN&C to converge to the 
most appropriate set of requirements. Similarly, performance requirements for propulsion instrumentation 
and avionics components are obtained from propulsion after intensive interaction between the avionics and 
propulsion design functions. Environmental requirements are obtained from the natural and induced 
environments groups: radiation, shock, vibroacoustics, and temperature. Avionics interacts with materials 
in determining the appropriate materials selection. 

Avionics consults with the system plane in the allocation of top-level requirements for cost, 
reliability, and maintainability. Most component performance requirements are derived requirements which 
flow from the respective organizations which have system design responsibility for that particular subsystem. 
Meeting the top-level requirement allocation with satisfactory performance usually entails iteration and 
feedback by avionics with the interfacing groups to converge to a design acceptable to all parties. 

4.3.93.2 Task 2 — Avionics Architecture. Based on initial requirements allocation and interaction 
with the system groups for the avionics subsystems, avionics identifies candidate architectures and component 
options directed toward meeting the requirements. Vehicle reliability and failure philosophy requirements, 
in conjunction with component reliability estimates, drive the requirement for redundancy which is a major 
factor in the architecture. Initial consideration is given to make/buy options, and a top-level assessment is 
made, comparing estimated system attributes of performance, cost, reliability, operability, etc., with their 
requirements. Significant difficulty in meeting requirements may necessitate iterations on requirements 
with the system and other design functions and disciplines at this stage. When reasonable compliance is 
achieved with satisfactory margins, detail design begins on the avionics subsystems. 

4.3.9.33 Task 3 — Avionics Subsystem Design. As with other parts of the vehicle, avionics subsystem 
design is of an iterative nature, entailing steps of greater fidelity and detail. Close coordination is maintained 
with the systems groups as the hardware/software definition refines. Since the systems groups are also 
iterating their designs to greater fidelity, requirements may change. Management of margins, primarily 
from experience base, plays an important role in minimizing requirement iterations. 

When the decision is to buy a component, the design function is replaced by detailed specification 
development, procurement, test, and verification. When the decision is to make a component, design 
proceeds through concept, simulation, analysis, preliminary design, breadboarding, detailed design, com- 
ponent testing, and integrated testing. The software design goes through a similar process as the hardware. 
As previously stated, because some of the software detailed requirements are derived during the avionics 
hardware design process, the software design may not reach maturity as soon as the hardware design. This 
must be recognized as a factor in the planning and scheduling of the vehicle development. 

43.9.3.4 Task 4 — Verification. The avionics components and the integrated avionics subsystem 
must be verified for functionality, performance, and compatibility with the environment it will experience. 
Verification is an iterative process as the flight components and EGSE are developed or procured, making 
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use of tiestbeds appropriate to the component or subsystem being tested. Function and performance are 
checked for the hardware elements over the range of variability that is expected to be encountered. 
Verification of the capability of the hardware to withstand its expected environments is accomplished by 
determining correct functioning before, during, and after testing in the pertinent environments — EMI, 
radiation, vibration, acoustics, thermal, and vacuum. Software is subjected to development, verification, 
and validation testing, exercising the software with as many combinations of inputs and operating conditions 
as possible. Depending on factors such as reliability requirements and cost, it may be desirable to subject 
the software to independent verification and validation testing; i.e., performed by those other than the 
developing organizations and personnel. Integrated testing of the avionics subsystem is accomplished on 
testbeds that combine flight-type avionics components with simulated or real interfacing hardware elements. 
These testbeds may be also used for software testing with both the simulated and real hardware elements. 
Final validation for both hardware and software is accomplished in flight testing. 

4.3.9.4 Avionics Implementation Function. The avionics design function provides the 
specifications and drawings required for fabricating the avionics hardware and generating the software. 
The avionics implementation function produces the hardware and software. The hardware specifications 
and drawings are developed in the design function based on the overall architecture decisions, as well as 
the philosophy and approach. Depending on these decisions, there may be long-lead procurement items 
which may need to be initiated soon after the end of the design function or, in some cases, prior to the end. 
The most common examples of the long-lead items are the highest reliability class of EEE parts. In 
implementation of the electronic subsystems, a breadboard system may be built and tested in the laboratory. 
For each subsystem, such as the flight computer subsystem, a unit tester is designed and built. The unit 
tester provides a stand-alone simulation of all interfaces with the ability to test the basic functionality of 
the subsystem. The decision may be made to build an engineering model for some subsystems which 
emulates the flight subsystem in “form, fit, and function.” The unit tester for the flight computer subsystem, 
as well as for some other subsystems, is useful for early software testing. Engineering models of the 
avionics subsystems may be used for subsystem testing of the design but are also the primary avionics 
components of the simulation laboratory that are used for avionics system and software testing. Qualification 
models may be built which contain identical parts and packaging as the flight system. The qualification 
models are used in the environmental and vibroacoustic testing phase. For one-time flights, the qualification 
model may become the flight unit which is commonly called protoflight hardware. For a flight vehicle 
avionics system design to be flown multiple times, the qualification model becomes the basis for the 
fabrication of the flight systems. 

In the design function phase of the software, design specifications are produced. The design 
specifications contain information such as the overall architecture and design of the software, a breakdown 
of the architecture into individual software modules, the detailed software-to-software and 
software-to-hardware interface definitions, the structure of the telemetry and command interfaces, and the 
definition of the methodology for implementation of the real-time requirements of the software. In the 
implementation phase, the individual software modules are coded and subjected to development testing. 
Appropriate groups of modules are integrated and tested. Timing analyses are conducted to ensure that the 
implementation of the design will meet the performance requirements. Ensuring that the real-time 
requirements are met in the software implementation is of critical importance. Once development testing 
is complete, the software modules are integrated and the verification and validation testing phase can 
begin. 
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4.3.10 Materials and Manufacturing Design Functions Overview 

The design properties of a material system are contingent on the manufacturing processes employed, 
both in the primary production and secondary shaping and assembly phase. Accordingly, the design functions 
of materials and manufacturing have been historically linked. Their interdependence in the modem era has 
been magnified by the rapid expansion in the development of both new materials and new processes. 

Composite materials, including metallic, nonmetallic, and combinations thereof, are examples 
of advanced structural material systems that challenge traditional design methodology. Many such systems 
require the development of design properties specific to individual component shapes. This differs from 
most metal alloy systems where the design properties for basic product forms (i.e., sheet, plate, extrusions 
etc.) are readily available and apply, independent of final component shape. When working with advanced 
structural material systems, it is often necessary to develop the manufacturing processes concurrent 
with the component design. The result is a “best fit” compromise between part configuration, weight, 
cost, and schedule. Assembly processes, such as welding and bonding which alter the properties of a 
material, also require special attention and clearly delineate the synergistic relationship between materials 
and manufacturing. 

Note: Executing the materials and manufacturing design functions is a complex process in itself, 
involving numerous disciplines and specialties. This document does not describe the process in detail but 
provides a top-level overview to show its relationship and interaction with the total vehicle design process. 
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Figure 66. Design process technical integration — materials design function. 


4.3.11 Materials Design Function 

Materials is considered a unique function. However, the distinctions between design functions and 
discipline functions are less rigid in the materials plane than in the more traditional design planes such as 
structures, propulsion, and avionics. Materials specialists interact directly with hardware designers and 
analysts throughout the design, development, test, and verification phases. This interaction is enhanced 
through the evolving integrated engineering environment which facilitates the immediate exchange of 
information across design planes and between discipline specialists. The relationship between the materials 
design function and other design functions is shown in figure 66. 
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4.3.11.1 Materials Design Function Plane. The materials design function plane is depicted in 
figure 67. The output of this plane is the materials design with all its inherent characteristics for a component, 
element, subsystem, or system. 

Informal 

Integration* 



Figure 67. Materials design function plane. 

The materials design function can be viewed simplistically as having overall responsibility for 
material selection, material control, and material performance. This responsibility extends to the full 
compliment of environments to which the materials are exposed, starting with their receipt and ending 
with their retirement from service. 


Unlike the more conventional visualization of a design function, the materials design function does 
not directly define a component configuration. Rather it provides design data and specifications regarding 
materials and commercial piece parts that becomes a part of the release documentation. 

The materials design function is associated with all other design functions in which a physical product 
(hardware) is being developed. Data bases, incorporating the mechanical and physical properties of virtually 
all conventional aerospace materials along with acceptance criteria for their use, are maintained and can be 
computer accessed by the design and analytical specialists. Additionally, it is the responsibility of the materials 
design function to review the evolving structural, thermal, propulsion, and avionics designs, develop further 
data where required, and approve the material selections and specifications contained in the release drawings. 
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Material specialists interact directly with process and manufacturing engineers to collectively assess 
the producibility of the design. They also identify long lead procurements and enabling technologies, along 
with their projected costs and development schedules. This becomes input to the other design planes where 
design features can be reconciled with resource and schedule allocations at the systems level. 

Material specialists also participate in acceptance and verification testing of component hardware 
and systems, assessing material performance, and providing structural failure analysis when required. 

The WBS elements 2.9, and tasks of reference 2 provide listings of inputs and outputs for the 
materials design function. The NxN diagram of reference 2 (app. A) is representative of further delineation 
of the associated inputs and outputs. The materials WBS elements are reproduced herein as figure 68 
and table 19. 
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Figure 68. WBS 2.9 — materials and processes design process flow diagram. 2 
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Table 19. WBS 2.9 — Materials design task description. 2 


Inputs 

Tasks 

Outputs 

• Drawings 
•Component function 

• Load/life requirements 

• Environment 
-Temperature 

- Humidity 

- Pressure 

• Accessibility 

• Design engineering 
and strength 
requirements 

• Special material 
requirements 

•MIUL 

• Assembly operations 

• Environment restrictions 

3.8.1 Compare candidate materials to 
MIL-HDBK-5 data 

3.8.2 Evaluate materials per MSFC- 
STD-506 and NHB 8060 
requirements: 

Including but not limited to: 
-Toughness 

- Compatibility with intended use 
environments 

-Life and aging 
-Corrosion, stress corrosion 
-Toxicity 

- Flammability 

- Reactivity 

- Flaw environmental and cyclic 
growth rates 

3.8.3 Evaluate fabrication and joining effects 

3.8.4 Develop NDE techniques 

3.8.5 Conduct static and fatigue tests to 
obtain missing and needed data 

3.8.6 Contamination analysis 

3.8.7 Cleanliness evaluation 

3.8.8 Critical processes evaluation 

3.8.9 Storage and shelf life evaluation 

3.8.10 Select materials and processes 

3.8.1 1 Qualification of weld and braze 
specimens 

3.8.1 2 Develop NDE techniques 

3.8.1 3 Develop contamination and cleanliness 
control plans 

•Fracture mechanics 
evaluation 

• Material selection options 

• Establishment and selection 
of fabrication techniques 

•Data for structural 
analysis 

• MUA 

• Materials selection and 
control plan 

•MIUL- final 

• Process specifications 

• NDE inspection and 
implementation 

• Procedures 

• Repair techniques 

• Hazardous operations 
evaluation 

• Process schedules 

• Personnel certification 
requirements 

• NDE plan and data for 
drawing input 

•Contamination and 
cleanliness plans 

Tools: 

• NASA and MIL data bases 


Key: • ELV, RLV, and RBCC 

RLV and RBCC 
•“ RBCC only 
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4.3.11.2 Materials Design Function Gates. Decision gates for the materials design function are 
shown in figure 69. They are (1) performance, (2) environmental compliance, (3) producibility/availability, 
and (4) cost/schedule. 



Figure 69. Materials design function gates. 


Functional performance is determined by test, considering applied loads, service environments, 
and service/cycle life. Environmental compliance requires a thorough researching of applicable Occupational 
Safety and Health Administration (OSHA)/Environmental Protection Agency (EPA) regulations regarding 
the control of hazardous materials. This extends to the production and use of a material or component and 
the operation of a device that produces hazardous waste products. Producibility involves interaction with 
potential suppliers to determine that all materials or elements of component design are available or can be 
provided. Special purpose materials not readily available on the commercial market may require vendor 
certification. This assures that the production processes are adequately controlled to provide a product with 
consistent properties. Certification is also required for critical secondary processes, welding and bonding 
for example, that can effect the properties of the assembled structure. Cost and schedule are self-explanatory. 
However, in most aerospace applications, the basic material costs are relatively minor contributors to the 
overall cost of the system and, generally, do not influence the design. 
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4.3.11.3 Material Tasks. The top-level tasks of the materials plane are shown in table 20. They 
consist of (1) requirements determination and allocation, (2) material selection and control, (3) material 
development, (4) materials testing and analysis, and (5) failure analysis. 


Table 20. Primary tasks for materials design function. 


Activities 

Interactions 

Tasks 

1. Requirements 
determination 
and allocation 

System 

Structures 

Thermal 

Propulsion 

Manufacturing 

1. Meet with system and design functions to identify 

initial requirements for material selection or development. 

2. Consult with system and design functions to establish 
safety factors and acceptable levels of risk to be reflected 
in the materials philosophy and criteria. 

3. Consult with manufacturing to confirm the adequacy of 
existing methods of fabrication or to determine the need 
for additional process development. 

4. Work with system and design functions to establish cost 
and schedule resource allocations. 

5. Work with system and design functions to reconcile 
nonconforming material issues, conduct trade studies, 
and, where necessary, revise requirement and/or 
resource allocations. 

2. Material selection 
and control 

Structures 

Thermal 

Propulsion 

Manufacturing 

Procurement 

Quality 

1. Consult with designers regarding acceptable material 
usage. 

2. Review and approve material specifications contained 
in design documentation. 

3. Develop and maintain material data bases. 

4. Consult with manufacturing to resolve primary and 
secondary material processing issues. 

5. Coordinate material supply issues with procurement 
and quality. 

6. Maintain material control records for critical hardware. 

3. Materials 
development 

System 

Structures 

Thermal 

Propulsion 

Manufacturing 

Quality 

1. Consult with design to obtain requirements for new 
materials. 

2. Consult with manufacturing regarding applicable 
processes. 

3. Work with quality to certify new materials and processes. 

4. Materials testing 
and analysis 

Structures 

Thermal 

Propulsion 

Manufacturing 

1 . Consult with designers regarding adequacy of available 
materials data. 

2. Perform testing to develop supplemental or “design 
specific” data. 

3. Coordinate specimen fabrication with manufacturing. 

5. Failure analysis 

Structures 

Thermal 

Propulsion 

Manufacturing 

Quality 

1 . Consult with design and quality to develop failure 
analysis plan. 

2. Coordinate specimen requirements for simulating service 
failures with design and manufacturing. 

3. Work across disciplines to implement failure analysis 
plan, develop fault trees, and coordinate supporting tests 
and documentation reviews. 
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4.3.11.3.1 Task 1 — Requirements Determination and Allocation. The allocation of materials 
requirements is determined jointly by the materials design function, the system design function, and other 
design functions that are users of the materials. Materials consults with the system design function and the 
user design functions to identify and flowdown the initial requirements for material selection or development. 
Typical requirements include mechanical and physical properties, compatibility with other materials and 
service environments, failure-mode constraints, environmental -compliance constraints, and cost and schedule 
constraints. While formal requirements allocations are made by the system design function, the materials 
design function has a central role in defining requirements and identifying an appropriate allocation. 
Likewise, the materials design function defines the materials selection and control philosophy and criteria 
that are then imposed formally from the system level. Metrics for the requirements are determined and 
included in the decision gates. If the material attributes do not meet the requirements and informal iteration 
among the design functions and disciplines cannot resolve the problem, the attributes and sensitivities are 
fed back to the systems function for trades and possible revision of the requirements allocation. As the 
design progresses, it is common for the requirements to be updated iteratively until convergence is achieved. 

4.3. 1 1 .3.2 Task 2 — Materials Selection and Control. Materials are selected based on their ability to 
function in the overall range of loads and environments to which they will be exposed. Selection further 
involves an assessment of the manufacturing processes to be employed, commercial availability, life cycle 
of the component, and, in some instances, cost. Initial material selections are generally made by the other 
appropriate design functions using information contained in a variety of databases. Material specialists 
assist in the selection when available data is insufficient, or where indepth assessment of viable material 
options is warranted. Material specialists also review the final material selections for all critical flight and 
test hardware and concur in the released documentation. 

The materials design function is the principal repository for materials data. It maintains a current data 
base on virtually all-conventional aerospace materials. This data base is continually updated as new information 
becomes available and can be readily accessed from any appropriately computer-equipped location. 

Material control, an element of configuration control, is also a primary responsibility of the materials 
design function with support from quality assurance. Material control is imposed on all critical flight 
hardware and associated test facilities. It requires that the location of all materials used in these applications 
be traceable and their pedigree verifiable. Issues such as cycle-life limits, out of specification service 
environments, quality escapes, and fraudulent parts drive the requirement for material control. 

4.3.1 1 .3.3 Task 3 — Materials Development. Materials development is undertaken by the materials 
design function in concert with the manufacturing and hardware design functions. Materials development 
is normally associated with research activities to extend the present state of the art for aerospace hardware. 
However, it can also be the result of unique aerospace requirements for which a broader commercial 
market is not apparent. Traditional suppliers often cannot justify investing their resources to produce these 
materials without government subsidy and/or indemnification. Interestingly, in many cases, broader markets 
evolve once these materials are developed and their properties characterized. 

4.3.1 1.3.4 Task A — Materials Testing and Analysis. Materials testing and materials analysis are 
performed to upgrade and supplement the design data base. Testing and analysis are also done to support 
unique design applications or assist in analyzing service or other hardware failures. Testing and analysis 
ranges over the full complement of standard assessment techniques for determining the physical and 
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mechanical properties of materials. It also includes simulated service testing in the environments unique to 
space flight, such as various forms of oxygen and hydrogen combined with high pressures and temperatures, 
testing corrosive media, and space radiation testing. 

Certain materials are batch sensitive; i.e., vagaries in the production process result in materials that 
differ in service performance from batch to batch. Some nonmetallic materials used in oxygen-rich 
environments, for example, must be tested for impact sensitivity and individual batches accepted for use 
based on the test result. 

Data from all tests are ultimately reviewed by material specialists for significance and accuracy. 
If it passes these screens, it is then submitted for inclusion in the materials data base. 

4.3. 1 1 .3.5 Task 5 — Failure Analysis. Assessment of material failures is performed by the materials 
design function. It is often conducted in concert with other design, analytical, and quality disciplines that 
interact to define the root cause of a component, system, or test-facility failure. The actual analysis of the 
failed hardware is preceded by a plan that assures evidence is not lost in the handling of the part or the 
sequence of dissection. Failure analysis employs a wide range of sophisticated diagnostic techniques. In 
many instances it requires simulating the failure in specifically designed test specimens under precisely 
controlled conditions. A fault tree is also a common tool used in exploring significant failure events. The 
fault tree starts with the resultant and explores all possible contributors, weighing and rejecting those that 
are less probable to arrive at the most probable cause. Fault trees are characteristically supported by analysis, 
testing, and detailed documentation reviews. 
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Figure 70. Design process technical integration — manufacturing design function. 


4.3.12 Manufacturing Design Function 

The manufacturing design function includes all activities associated with the definition and 
implementation of the manufacturing process. The relationship between the manufacturing design function 
and other design functions is shown in figure 70. 

4.3.12.1 Manufacturing Design Function Plane. The manufacturing design function plane is 
depicted in figure 71. The main output of this plane is planning and documentation to specify fabrication, 
inspection, certification, and test. Residing on the manufacturing plane are the subelements involved in the 
manufacturing activity. The significant subelements are described in limited detail in section 4.3.12.3. 
They are requirements determination and allocation; planning, scheduling, and cost; process development 
and certification; tool design and development; subcontractor/vendor selection and control; and parts 
fabrication and assembly. 
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Figure 7 1 . Manufacturing design function plane. 


Manufacturing has overall responsibility for producing hardware in compliance with program demands 
and the requirements of the released design documentation. Manufacturing engineers and planners interact 
with process engineers, hardware designers, analysts, quality and safety personnel, contracting personnel, 
material specialists, project engineers, vendors, and contractors throughout the manufacturing cycle. These 
interactions are necessary to coordinate changes, adjust schedules, determine the disposition of discrepant 
hardware, and react to program redirection or unforeseen problems that may impact cost or schedule. 

The WBS elements 2.14 and tasks of reference 2 provide listings of inputs and outputs for the 
manufacturing design function. The NxN diagram of reference 2 (app. A) is representative of further 
delineation of the associated inputs and outputs. The manufacturing WBS elements are reproduced herein 
as figure 72 and table 2 1 . 
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Design 

• Materials 

• Propulsion 

• Reliability 

• Cost 


Consultation 

Options 

Trades 

Analysis 

Cost 

L 


Manufacturing and Assembly Analysis 

• Fabrication/Joining Techniques 

• Fabrication Practices: 

-Forging 

-Casting 

-Weldment 

-Composite 
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• Manufacturing 
and Control 
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• Assembly and 
Verification Plan 

• Make or Buy 
Plan 


Figure 72. WBS 2.14 — manufacturing design process flow diagram. 2 


Table 21. WBS 2.14 — manufacturing process task description. 2 


Inputs 

Tasks 

Outputs 

• Drawings 

• Component function 

• Assembly operations 

• Schedules 

• Inspection and assurance 
requirements 

• Cost restrictions 

• NDE plan 

• Cleanliness plan 

• Contamination plan 

• Quality plan 

3.14.1 Develop fabrication and joining techniques 

3.14.2 Evaluate fabrication practice: 

- Forging 

- Casting 
-Weldment 

- Composite 
-Adhesive 
-Joining 
-Etc. 

3.14.3 Evaluate material form and selection for 
best manufacturing practice 

• Input for drawings, notes, 
specifications, etc. 

• Hardware control 

• Manufacturing control plan 

• Assembly and verification plan 

• Make or buy plan input 

Tools: 

• NASA and MIL databases 


Key: • ELV, RLV, and RBCC 

- RLV and RBCC 

"• RBCC only 
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4.3.12.2 Manufacturing Design Function Gates. Decision gates for the manufacturing design 
function are shown in figure 73. They are (1) producibility, (2) robustness, (3) system performance, 
(4) logistics, (5) environmental compliance, and (6) cost and schedule. 



Figure 73. Manufacturing design function gates. 


Producibility is addressed early in the design of a component or assembly and continues throughout 
the design process. Manufacturing engineers participate directly with designers, analysts, and material 
specialists to assure that the component or assembly can be produced and that appropriate manufacturing 
requirements are incorporated within the design. Often these take the form of modifications to reduce cost 
or simplify the manufacturing process. Producibility reviews also address the availability and adequacy of 
proposed facilities, material suppliers, and parts vendors to support the project. Items that require long lead 
times for procurement or new processes for their production are identified in the producibility reviews, 
along with projected costs and development schedules. The output of the producibility reviews becomes 
input to the other design planes where design features can then be conformed to resource and schedule 
allocations at the systems level. 

Robustness is generally inherent in well established manufacturing processes but is often lacking in 
newly developed processes. These frequently rely heavily on operator skill to produce a satisfactory product. 
Before a new process is placed into production, formal operating procedures are developed and rigid tooling 
and/or modem control systems added. These promote consistency in the process and add to its robustness. 
They also reduce the need for highly skilled operators by limiting and controlling the degree of operator 
interaction allowed in the process. 
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System performance reflects the ability of the full complement of manufacturing activities to achieve 
the requirements established by the design functions. Typical requirements include dimensions and 
tolerances, material properties, inspection criteria, and maintenance criteria. System performance is a key 
attribute of the manufacturing function. 

The logistics gate involves interaction with designers, analysts, and transportation specialists to 
assure safe packaging and transportation of large and/or delicate assemblies. Environmental compliance 
requires thorough research of applicable OSHA/EPA regulations regarding the control of hazardous materials. 
This research extends to the use and disposal of toxic materials employed in the manufacturing process and 
the protection of workers involved in these processes. The cost and schedule gate is self explanatory. 

It is important to note that the manufacturing phase of launch vehicle development places heavy 
demands on program assets. It is advisable to allocate adequate time and resources to optimize the design 
prior to its release. Changes made to the design after its release typically have a much greater negative 
impact on both cost and schedule than changes made earlier in the project. 

4.3.12.3 Manufacturing Tasks. The primary tasks of the manufacturing plane are shown in 
table 22. They consist of (1) requirements determination and allocation; (2) planning, scheduling, and cost; 
(3) process development and certification; (4) tool design and development; (5) subcontractor/supplier 
selection and control; and (6) parts fabrication and assembly. 

4.3. 12.3. 1 Task 1 — Requirements Determination and Allocation. The determination of manufacturing 
requirements and constraints is achieved by the manufacturing design function in conjunction with the 
system design function and other design functions that interact with manufacturing. These requirements 
and constraints are then allocated to manufacturing via the system plane and this flowdown initiates the 
manufacturing activities. The system design plane controls formal allocation of requirements and constraints. 
The manufacturing design function, however, has a central role in defining them and identifying appropriate 
allocations. Typical requirements and constraints include critical process identification, process verification, 
operator training, environmental compliance constraints, facility and process constraints, and cost and 
schedule constraints. The manufacturing design function also identifies the manufacturing philosophy and 
criteria which are then formally imposed by the design function. Metrics for the requirements are determined 
for the decision gates. When the manufacturing attributes cannot support the imposed requirements, informal 
discussions between the design functions are initiated. If the problem cannot be resolved in this manner, 
the attributes and sensitivities are fed back to the system design function for trades and possible revision of 
the requirements allocation. 

4.3.12.3.2 Task 2 — Planning, Scheduling, and Cost. Planning and scheduling begin in the early 
stages of the producibility reviews and mature into the detailed production control documents that govern 
the manufacturing effort. Written process instructions which also contain the inspection requirements of 
the quality control organization are generally adequate to manage small projects. However, large, complex 
projects often require that the manufacturing philosophy be defined in a comprehensive manufacturing 
plan. Development of this plan parallels development of the design and is normally a data requirement of 
any procurement effort having a major manufacturing component. The manufacturing plan outlines the 
tooling concepts and manufacturing processes to be employed and identifies any new processes that must 
be developed and certified. It describes vendor and supplier requirements, inspection requirements, and 
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Table 22. Primary tasks for manufacturing design function. 


Activities 

Interactions 

Tasks 

1. Requirements 
determination and 
allocation 

System 

Structures 

Thermal 

Propulsion 

Manufacturing 

1 . Meet with system and design functions to identify initial 
requirements and constraints. 

2. Consult with materials regarding unique material 
processing requirements. 

3. Work with system and design functions to conduct trade 
studies and establish cost and schedule resource allocations. 

2. Planning, scheduling 
and cost 

Project 

System 

Structures 

Thermal 

Propulsion 

Materials 

Procurement 

Quality 

1. Work with design, materials, quality, and procurement 
to define the manufacturing approach or develop the 
manufacturing plan. 

2. Work with project, system and design to identify new 
facility requirements. 

3. Consult with project, system and design to reconcile priority, 
cost, and schedule issues. 

3. Process 
development and 
certification 

Structures 

Thermal 

Propulsion 

Materials 

Procurement 

Quality 

1. Meet with design and materials to establish requirements 
for new manufacturing processes. 

2. Work with process and material engineers to develop new 
manufacturing methods. 

3. Work with procurement and/or quality to certify new 
manufacturing methods. 

4. Tool design and 
development 

Project 

System 

Structures 

Thermal 

Propulsion 

Procurement 

Materials 

Quality 

1 . Coordinate tooling requirements and approach with 
design and materials. 

2. Reconcile cost and schedule issues with project and system. 

3. Work with procurement and/or design to acquire tool 
documentation and hardware. 

4. Coordinate tool certification with design, materials, and quality. 

5. Subcontractor/ 
supplier selection 
and control 

Project 

System 

Design 

Materials 

Procurement 

Quality 

1. Meet with project, system, design, and materials to 
reconcile unique or sole source supplier issues. 

2. Work with procurement and quality to identify and certify 
viable suppliers and contractors. 

6. Parts fabrication 
and assembly 

Project 

System 

Structures 

Thermal 

Propulsion 

Materials 

Quality 

Procurement 

1. Create detailed process specifications and work planning 
documents in concert with design, materials, and quality. 

2. Work with quality to train and certify technicians to perform 
critical process operations. 

3. Fabricate and assemble parts and coordinate changes 
with design. 

4. Meet with interacting disciplines to disposition discrepant 
hardware, resolve problems, or react to program redirection. 



any new facilities needed. The major tools and processes unique to the project are displayed in illustrations. 
The flow of parts through the subassembly and inspection stations to final assembly is diagrammed in 
factory floor layouts. The manufacturing plan and its implementation cost are major discriminators in 
selecting a prime contractor for launch vehicle production. 

Scheduling a new manufacturing effort cannot be done independent of other manufacturing facility 
commitments. Priorities must be established, milestone accomplishments determined, and a start and 
completion date negotiated. Critical path scheduling within and across projects optimizes the application 
of resources and aids in meeting major project milestones. However, changing priorities, late delivery of 
vendor supplied items, manufacturing mistakes, and design changes all contribute to schedule delays. 
Controlling these factors requires a systems approach that cuts across functions and disciplines. Successful 
results are achieved by appropriately scheduling reviews and establishing clear lines of communication. 

4.3. 12.3.3 Task 3 — Process Development and Certification. Traditional processes will be employed 
when manufacturing the majority of components for a launch vehicle. These processes have thoroughly 
established standards and controls. However, achieving higher performance in a new launch vehicle may 
not be possible using only traditional processes. Invariably, the introduction of new materials or shapes 
occurs in select areas of the design. These often require that established processes be modified or that 
entirely new processes be developed and certified. Projecting the time and resources required to perfect a 
new material or process is an inexact science and is best accomplished by a team of discipline specialists. 

Occasionally program demands force the development of secondary manufacturing processes to 
proceed concurrent with development of the new material itself, with changes in one area affecting the 
other. An excellent example of this is in the space shuttle external tank. A new aluminum lithium alloy was 
introduced to improve performance. Attempts to weld this new alloy identified an extreme sensitivity to 
constituent levels and other parameters employed in its production. Major modifications to both the alloy 
and the welding processes were necessary. These changes extended over many months and successful 
resolution required a coordinated effort between discipline specialists from the material supplier, the external 
tank contractor, MSFC, and contributing consultants. 

Many manufacturing processes contain within them a number of parameters considered critical to 
achieving a consistent result. Modem process development employs statistical methods to limit the number 
of tests that are required on combinations of these critical parameters for process optimization. Once the 
process is optimized, it must be certified. This certification is supported by process sensitivity studies. 
These studies establish the limits to be placed on each critical process parameter to assure material design 
properties are not compromised. 

4.3.12.3.4 Task 4 — Tool Design and Development. Tooling is generally understood to include such 
items as jigs, work platforms, handling slings, transportation dollies, assembly fixtures, and other similar 
devices to hold, manipulate, or move parts throughout the various stages of manufacturing. While some 
tooling may support several projects, the major tools for a new program are configuration unique. These 
tools must be considered during the early stages of the program since long lead times are required for their 
design and construction. 

Tooling represents a major program cost element and can be a significant factor affecting both 
production schedules and product quality. A careful balance must be struck between the use of “hard” and 
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“soft” tooling in the more demanding phases of production. Hard tooling strives to maximize rigidity and 
maintain the desired spatial relationship between part and process equipment throughout each operation. 
Hard tooling is more expensive to employ and takes longer to design and fabricate. However, its more 
precise features reduce the risk of failure and work arounds during startup. Also, the use of hard tooling 
generally results in fewer process defects and faster turn around times. Soft tooling strives to achieve the 
same result as hard tooling but is generally less rigid, with fewer automated features or assembly aids. 

Advancements in multipurpose process systems employing robots, sensors, and part positioners 
linked by a computer are reducing the performance gap between hard and soft tooling. However, most 
large manufacturing efforts still employ a mix of hard and soft tooling, with the selection for each process 
driven by control requirements, schedules, and other budgeted resources. Design engineers, analysts, process 
engineers, and manufacturing specialists must work collectively to define the appropriate tooling approach 
best suited to the program constraints of cost and schedule. 

4.3.12.3.5 Task 5— Subcontractor/Supplier Selection and Control. Small projects often are 
accomplished at one location without subcontract support and with supplier participation limited to the 
provisioning of raw materials or commercial piece parts. As projects grow in scope and complexity, reliance 
on subcontractors and outside suppliers increases. Four common factors influence the decision to use 
outside contractors. These are ( 1 ) the capacity of the principal fabricator to absorb the work involved in the 
new project, (2) the relative cost of doing the work in-house versus by contract, (3) the capability of the 
principal fabricator to perform a required function, and (4) government regulations requiring that portions 
of the work be contracted out. 

Subcontractor and supplier selections are critical to program success. Their performance affects the 
cost, schedule, and quality of the delivered items. Specialists in manufacturing, materials, quality control, 
and procurement must work together to certify that each new subcontractor or material supplier has the 
capability and controls to produce an acceptable product. The process of certification has been greatly 
enhanced in recent years by the wide spread acceptance of criteria emanating from the ISO. Contractors 
with ISO certification have demonstrated that they have in-place a documented set of procedures that are 
adequate to control all facets of the work they perform, as well as satisfactory training of the personnel 
employing these procedures. Maintaining certification requires regular audit and approval by trained 
representatives of ISO. 

Special attention must be given to sole source suppliers. Every effort should be made in the design 
and material selection phase of the project to circumvent their use. Sole source suppliers produce a product 
that is unique or of such limited marketability that competitive interest in the field is suppressed. Occasionally, 
the commercial outlet for a sole source supplier’s product is reduced to the point that continued production 
is no longer economically viable. When this occurs, programs that rely on such materials may be required 
to subsidize the supplier to maintain production, fund the acquisition of alternate sources, or develop and 
qualify a replacement material. Any of these options can have serious cost and schedule impacts. 

4.3. 12.3.6 Task 6 — Parts Fabrication and Assembly. The design of a component or assembly assures 
its final form in the manufacturing process. Manufacturing engineers and production control specialists 
define the processes to be used and the sequence in which they are to be performed. Skilled tradesmen are 
then required to implement each activity. Critical processes require that operators are trained and certified 
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in their use. Certifications are time limited and operators must be recertified at prescribed intervals. All 
critical processes and many noncritical processes are supported by detailed process instructions resident at 
each workstation or contained in the “shop travelers.” These are the planning documents that direct the 
flow of parts through each step of manufacturing. These documents also contain the specified inspection 
points and requisite approval stamps certifying that the right parts and materials were used and that the 
operations were performed correctly. Although described as documents, the planning paper is frequently 
computer generated and displayed on interactive monitors at each process station. 

4.3.12.4 Manufacturing Implementation Function. While the manufacturing design function 
results in planning and documenting the manufacturing process, the manufacturing implementation function 
produces the hardware. Manufacturing resides midway in the life-cycle flow for a new vehicle. Requirements 
definition and hardware design precede it. Implementation of the manufacturing function begins with the 
flowdown of requirements from the system plane. Hardware production, however, is generally not initiated 
until the final design documentation is released. Verification follows manufacturing. Should the verification 
activities fail to confirm all hardware design requirements, further iteration of the design with manufacturing 
is conducted. The process is repeated until convergence is achieved between design requirements and 
hardware performance. Operations is considered the last step in the life-cycle flow for a new vehicle. 
However, it is customary in programs having very long periods of operation for the life-cycle flow process 
to be repeated, albeit in abbreviated form. Program exigencies and/or evolving technologies which offer 
opportunities to improve vehicle performance or reduce operational cost are the catalysts for reinitiating 
the life-cycle flow process. 

4.3.13 Other Design Functions 

The design functions delineated in the previous sections are primary to the design and development 
of the launch vehicle. Through the activity of subsystem compartmentalization, all hardware and software 
products are defined. Subsequently, the major subsystem design functions are determined. 

There are hardware and software items that do not belong to any of the major vehicle subsystems. 
They are denoted as auxiliary subsystems. However, the function of these auxiliary subsystems is critical 
to the successful flight of the vehicle. Their design activities may require fewer design functions and 
disciplines then that of the major subsystems. In addition, the number of interactions may be less, there 
may be fewer design iterations, there could be less technical integration, or they are specialty/unique items. 
As a consequence, the design functions of those subsystems are not allocated a specific plane but are 
grouped as “Other Design Functions” in figure 26. Typical examples of these auxiliary subsystems include 
recovery systems, landing gear, environmental control and life support system (ECLSS), crew interface, 
payload conditioning, pyrotechnics, GSE, etc. Whenever a subsystem design is influenced by one of these 
auxiliary subsystems, the design function of the auxiliary subsystem is represented by the “Other Design 
Functions” plane. 

4.3.14 Reintegration Into the Complete System 

Figure 9 in section 2. 1 illustrated three types of compartmentalization: the system into subsytems, 
the subsystems into design functions, and the design functions into disciplines. Each of these compartmen- 
talizations requires reintegration to reconstitute the total system. Figure 27 provides another view of this 
process. On the upper left is an example subsystem tree which illustrates compartmentalization of the 
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vehicle hardware and software into smaller and smaller entities. Each of these hardware/software entities 
has an associated design function stack, as shown on the upper right of the figure. Each design function 
plane contains discipline activities. So, the tree represents subsystem compartmentalization, and the stacks 
represent design function and discipline compartmentalization. 

On the lower left, there is an Ixl diagram, which represents information flow associated with the 
subsystem tree interfaces. On the lower right is shown the NxN diagram which represents information 
flow among the design functions and disciplines, as discussed previously. An important feature that aids in 
the reintegration process is modeling provided by the disciplines on the design function planes. The mod- 
eling provides a means for accounting for interactions, nonlinearities, incompatibility, and uncertainties 
that are inherent throughout the reintegration process. The models enable the analysts to perform trade 
studies and sensitivity analyses that can be applied to desensitize any of the aforementioned undesirable 
effects and to assess their effects in order to provide adequate margins. Models applied in this manner 
provide the necessary understanding of the reintegrated hardware/software systems along with a high 
level of confidence regarding flight safety. 

As stated, each of the three compartmentalizations requires reintegration. Reintegration begins 
with integrating the disciplines into the design functions, then integrating the design functions into 
subsystem designs, then integrating the subsystems into the complete system. 

This finally completes the process of reintegrating the subsystems into a total system design. 
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4.4 Design Sequence 


The elements and connections of the design process have been described in the previous section, 
along with specific tasks that are accomplished on and between the various design function planes. This 
section will address the time sequence of activities that comprise the stages of the design process. There are 
two parts; Section 4.4.1 describes the conceptual design stage and section 4.4.2 describes the preliminary 
design and detail design stages. 

4.4.1 Conceptual Design Stage 


The conceptual design stage is the early part of the vehicle design process which begins with 
hypothesizing candidate concepts to fulfill the given mission statement and typically extends to the 
beginning of the preliminary design stage. Concept selection is the downselection to one concept. Concept 
selection ordinarily occurs before starting preliminary design; however, in some cases, multiple concepts 
are carried through preliminary design, and in the case of a 4 fly-off, multiple concepts are carried through 
detail design, manufacturing, and verification. 

4.4.1. 1 Importance of Conceptual Design Stage. The conceptual design stage is crucial to the 
success of the total design process and the resulting vehicle system. It has been estimated that at least 
80 percent of a vehicle’s life-cycle cost is locked in by the concept that is chosen (see fig. 74). Another way 
of saying this is that choices made during preliminary design, detail design, manufacturing, and operations 
(although essential) can have no more than a minority effect on determining life-cycle cost. While poor 
detail design engineering can mess up a good concept, the best detailed design engineering will not correct 
a flawed concept design and selection. The right concept selection is critical. 



1. Conceptual Design 

2. Preliminary Design 

3. Detailed Design 

4. Manufacturing and System Integration/Verification 

Figure 74. Representative percentage of system life-cycle cost determined as a function of design stage. 
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A significant element of the life cycle cost occurs during vehicle development. Inadequate phase A 
& B activity is known to result in program developmental cost overruns. Empirical evidence of the influence 
of conceptual and preliminary design efforts on final program costs is shown in figure 75 from reference 4. 
Illustrated in this figure is the final cost as excess over the initial phase C commitment as a function of cost 
in phases A and B as percent of development cost for a number of NASA programs. It can be seen that 
when programs are initially underfunded (i.e., not enough up-front design effort), cost overruns can be 
expected. Thus, insufficient efforts in the early design process will impact program life cycle costs resulting 
in developmental cost overruns. Another aspect of the life cycle cost is flight and ground operations. There 
is anecdotal evidence that inadequate up-front design efforts will also result in increased operations costs. 



Source : Presentation by Werner Gruhl, 
Office of the Comptroller ; NASA HQ, 1985 



Costs in Phases A and B as Percent of Development Cost 


Figure 75. Cost overruns in NASA programs. 


The aforementioned implies that we must put sufficient effort into front-end engineering during 
conceptual design. Here the familiar quality lever is at work (see fig. 76). The quality lever idea is that 
conceptual design decisions have a 100: 1 leverage on end-product quality and cost; preliminary design has 
a 10:1 leverage; detail design drops to 1:1; and, during the operations stage, the leverage may reverse to 
1:10. Make use of the leverage, and put the necessary effort at the front end. 
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4.4.1.2 Convergence of Process. Conceptual design and selection are a converging process, initiated 
by a mission statement, and concluding with a selected concept to proceed into preliminary design. It 
follows a series of iterations that include generating hypothesized concepts, evaluating the concepts, and 
discarding unfavorable concepts. This was illustrated in a previous section in figure 13. Each successive 
iteration entails describing and evaluating the remaining concepts in greater detail than for the previous 
iteration. Thus, an iterative downselection is accomplished to fewer concepts, with increased penetration 
on each iteration. New concepts may be introduced and requirements may be refined at each iteration. A 
change in requirements necessitates a look at new and previously discarded concepts in light of the revision. 
The process is completed upon selection of a single concept to carry forward into preliminary design, or in 
some cases, multiple concepts to carry forward. A program might choose to carry multiple concepts forward 
if no clear-cut winner is apparent without going to the level of detail entailed in preliminary design or if a 
fly-off philosophy is used (for which the program must have sufficient development resources). 

4.4.1.3 Conceptual Design Activity Sequence. An overview of the conceptual design process is 
illustrated in figure 77. The activity sequence begins with the program providing a mission statement and 
initial requirements that specify objectives and constraints for performance, cost, reliability, safety, 
operability, and schedule, and indicate any TRL constraints, etc. In addition, program-level strategy and 
philosophy are identified. Typically, the initial program requirements are expanded and refined as the 
concept iterations proceed. This is even more true of the program strategy and philosophy which initially 
are rudimentary and high level and are modified and expanded as the concepts mature. 

Given these requirements and strategies, creative designers and idea generators conceive of 
candidate vehicle system options that may meet the requirements. Functional decomposition is used to 
guide the idea generation process. Sketches of architectural options put form to these ideas, and concept 
evaluation criteria are selected. Concept evaluation criteria will include the attributes of performance, cost, 
reliability, etc., corresponding to top-level program requirements. Other measures such as dry weight 
margin sensitivity as a function of dry weight may be included as appropriate. 

At this point, an informal screening may eliminate concepts that are clearly not competitive (but if 
in any doubt, leave the concept in!). The remaining concepts are then subjected to quantitative evaluation. 
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Outputs 

— ► Sized 

Configuration 

— ► Concept Layout 
and Attributes 

— ► Margins 

— ► Technology 
Maturation 
Requirements 

— ► Risk 

Assessment 

Potential Iterated 
Requirements and 
Concept Ideas 


Figure 77. Conceptual design stage — sizing and functional flow sequence. 


Each competing concept is characterized at the idea-sketch level and is set up in a sizing program. 
In this report, the term “sizing program” applies to the set of interconnected programs that manipulate top- 
level system variables and “rubberized” subsystem descriptors to converge to a consistent set of vehicle/ 
subsystem weights and performance. Variables in the sizing program may be free to change, or may be 
fixed at the concept designer’s discretion. The iterative sizing process is started with initial estimates of 
basic aerodynamics (drag, lift), propulsion characteristics (thrust, I sp ), and weights. These initial estimates 
are used in an initial performance/trajectory assessment, which then feeds a propellant volume sizing 
adjustment. The adjusted volume is represented in a concept configuration layout that includes subsystems 
reflecting the adjusted volume. An assessment of the adjusted subsystems leads to updates in the aerody- 
namics, propulsion characteristics, and weight estimates. This iterative process continues until the sizing 
and performance have converged. 

Since current sizing programs are approximate tools with significant simplifying assumptions, an 
assessment of each concept is required by design and discipline specialists. Initially, this assessment typi- 
cally consists of an overview of sizing program assumptions, inputs, and outputs by a small group of 
experienced specialists. These specialists provide the subsystem assessment shown in figure 77, carried 
beyond the level of detail included in the sizing program. The fidelity then may be augmented with more 
detailed analyses and assessments by additional discipline specialists. By the time the design reaches the 
preliminary design stage, the need for fidelity has exceeded the capability of current sizing programs, and 
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the design functions are performed by design specialists in each area. The transition from the design func- 
tions being performed by the sizing program to being performed by specialists ordinarily occurs in the 
latter part of the conceptual design stage. 

The outputs of the conceptual design process include (1) the sized configuration, (2) an updated 
concept layout, (3) estimates of the concept attributes (these include cost and -ility attributes in addition to 
the performance attributes represented in the flow cycle of figure 78), (4) identification of margins appro- 
priate to the uncertainties and sensitivities of the concept, (5) identification of technologies needed and 
their maturation requirements, and (6) a risk assessment. The process frequently results in a need to iterate 
the requirements or in generation of new concept ideas. 

Technologies required for each concept are identified, technology readiness levels are determined, 
and the effort to bring the technologies to maturity is scoped. The primary attributes of cost, operability, 
etc., are estimated. Top-level system failure modes are identified, and a risk assessment for each concept is 
performed. This includes assessing performance risk, cost risk, and schedule risk, and a potential risk 
mitigation plan. 

All competing concepts are assessed in a matrix of attributes that reflect evaluation criteria 
including refined top-level requirements. The concept evaluation criteria are used to evaluate and downselect 
among the concepts. Downselection reduces the number of competing concepts and allows for the 
introduction of additional concepts at this point, if additional ideas have been generated by the process. 
Concepts may be modified in a direction indicated by the analysis and evaluation process. In addition, it 
is typical for concept evaluation to reveal the need to modify or refine the system requirements or 
philosophy. 

Those concepts that remain after downselection are defined in greater detail, and more detailed 
analysis is performed, repeating the cycle until a final concept is selected. In some programs, competing 
concepts are carried through manufacturing and testing before final selection is made. Throughout the 
concept design and selection process, it is crucial to consider uncertainty and sensitivity and to carry 
margins appropriate to the fidelity of the system definition. There is not a single set of margins which are 
correct for all projects, because the appropriate margins depend on the characteristics of the project. Highly 
interconnected vehicles and those using more advanced technology should use higher margins than their 
simpler or more conventional counterparts. A well characterized vehicle should have at least 20 percent 
performance margin at the end of the conceptual design stage. More complex vehicles or those requiring 
significant technology development should have greater margin — up to 30 or even 50 percent, depending 
on the specific situation. 

4.4.1. 4 Process for More Indepth Assessment. The process indicated in figure 77 represents the 
internal interactions of the sizing program as augmented by a small number of discipline and design func- 
tion specialists. For concepts that are relatively close to the experience base and have relatively low sensi- 
tivity and uncertainty, the process represented on the figure is adequate for conceptual design. If there are 
very high sensitivities and uncertainties, or if the concept is highly unconventional, a more indepth 
assessment is required to achieve the correct conceptual design. In this case, a larger group of design and 
discipline function specialists are needed to provide the increased penetration. 
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Figure 78 illustrates the more indepth assessment from a structures/thermal/flight mechanics per- 
spective. There would be similar processes for more indepth assessments of the propulsion and avionics 
systems. The process starts with the concept definition and outputs from figure 77, and proceeds as 
indicated to put more realism into the concept design. That is, iterations are made through the indicated 
disciplines to bring the concept to a more refined definition that is consistent with the physical realities 
represented by the disciplines. 


Start Process for 
Configuration “n” 



Figure 78. Conceptual design stage — process for more indepth assessment. 

(Structures/thermal/flight mechanics perspective.) 

The process shown in figure 78 is detailed and complex, involving many concurrent activities and 
interactions. The individual design functions and disciplines execute their respective tasks as best deter- 
mined by the persons comprising those design functions and disciplines. Detailing these design and disci- 
pline-specific activities is beyond the scope of this report; however, there is an overall pattern and 
sequence that will be addressed below. 


Major steps in the process for each competing concept include the following: 


a. Put form to the concept. 

• Make initial sketches 

• Estimate initial configuration parameters (elements, size, mass, etc.) 

b. Estimate primary propulsion system characteristics. 

c. Estimate primary aerodynamics. 

• Total forces and moments for trajectories 

• Distribute forces and moments for loads and control 
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d. Perform basic trajectory/performance analysis, iterating among structures (weight), propulsion, 
and aerodynamics to size the vehicle for the required payload. 

e. Generate baseline trajectory and design reference trajectories. Include trajectory shaping 
constraints based on abort or recovery requirements. 

f. Determine the control system philosophy, logic, and architecture, based on experience. 

g. Determine control authority, and analyze rigid body control response to variations in key 
parameters. 

• Variations in aerodynamics, propulsion, mass properties, etc. 

• Use load indicators 

h. Assess key stability issues if they appear to be significant design drivers. 

• Aeroelasticity, propellant sloshing, Pogo 

i. Determine bounding vehicle loads for each flight event. 

• Lift-off 

• Ascent 

• Reentry 

• Landing and recovery 

j. Conduct an overall stress analysis to assess top-level design. 

• Use fundamental versus finite element analysis 

k. Iterate with structural designers to converge structures configuration. 

l. Select TPS and thermal control system concepts (concurrent). 

• Determine thermal environments from thermal reference trajectory and natural environments 

• Obtain surface weight/density allowance 

• Develop options 

• Select TPS and thermal control system concepts 

m. Develop conceptual propulsion system definition (concurrent). 

• Propellants 

• Components 

• Weight and performance 

n. Develop conceptual avionics system definition (concurrent). 

• Components 

• Redundancy 

• Power, weight, cost 
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o. Develop conceptual definition of auxiliary systems, sufficient for estimating weights, size, cost, 

and effects on major subsystems. 

• Separation systems 

• Landing, recovery systems 

• Pyrotechnics, etc. 

p. Identify initial production and operations plan. 

q. Refine design content of concept. 

• Material, mass distribution, type and size of element, etc. 

• Induced environments 

• Sensitivities 

• Margins 

r. Iterate at each level to arrive at a converged configuration. 

s. Assess attributes, technologies, and risks in view of system requirements. 

4.4.1.5 Overall Integration. During the conceptual design stage, the project leader and the systems 
discipline are heavily involved in all major activities and associated decisions. These activities consist of 
developing concepts and project requirements, constraints, philosophies, procedures, criteria, and guidelines 
that are required to be mutually compatible. During this process, inputs are received from all technical 
areas including operations. Consideration is focused on the concept(s) attributes of performance, cost, 
reliability, safety, schedule, operability, failure modes, and the TRL constraints. The necessary mutual 
compatibility is achieved with the aid of formal and informal integration. Formal integration is accomplished 
by the leader on the system plane, supported by system engineers, discipline engineers, functional managers, 
and working groups. Their focus, as stated above, is developing concepts with balanced attributes that 
satisfy the requirements, constraints, philosophies, procedures, criteria, and guidelines. 

As shown in figure 79, the formal integration is horizontal and, in the conceptual design stage, 
predominates informal integration. The functional flow sequence associated with formal integration is 
shown in figure 77. This activity is orchestrated by the leader and represents the initial system design 
function. The informal integration is accomplished by design and discipline engineers. Their initial activi- 
ties consist of subsystem assessments for structures, propulsion, thermal, GN&C, avionics, operations, and 
others that could have a significant impact. It is noted that these subsystems or a variation eventually 
become the vehicle-level design functions as the design progresses. After the subsystem assessments are 
completed they are formally integrated into the conceptual design process. Then the entire conceptual 
design is reevaluated as an integrated system. If there is conflict and balance cannot be achieved, then the 
system plane is required to resolve the conflict. This can result in changing the requirements, constraints, 
philosophies, procedures, criteria, and guidelines in an overall sense or rebalancing them among the sub- 
systems. At this stage of the design process, the informal activities are at a lower level than the formal 
activities, as shown in the figure. However, the informal input from the design and discipline engineers is 
very important since they represent the core technical assessment. These inputs at this stage of the design 
process can significantly impact the downstream preliminary and detailed design processes. Every effort 
should be made to achieve balance and convergence at this stage and avoid delaying the balance to a later 
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design phase. In some programs the balance has been delayed when new technologies were required to be 
developed to achieve program success. In other cases, balance was delayed because mass fraction could 
not be achieved early in the conceptual design stage. These shortcomings during the conceptual design 
process resulted in subsequent program delays and rework and in operational complexity which increased 
operational cost. 


Not Active 



• Formal • Informal 

- Chief Engineer - Design Function and Discipline Engineers 

- System Engineering Manager - Functional Managers 

- System Engineers - Panels 

- Functional Managers 
-Working Groups 


Figure 79. Conceptual design stage — overall integration. 


4.4.1.6 Ideas and Options. During the idea-generation stage of conceptual design, the full range 
of possible options to satisfy the mission statement should be explored. An option that is not brought forth 
as a concept to be evaluated misses the cut by default. Figure 80 indicates example subsystem options to be 
considered in developing candidate concepts. The options on this list are not nearly exhaustive but are 
included as reminders of major options that may be chosen. 

4.4.1.7 Conceptual Design Stage Products. The primary product of the conceptual design stage 
is the concept or concepts that have been downselected to proceed to the next stage, preliminary design. 
The downselected concept will have been screened for feasibility at a relatively low level of detail and 
should have appropriate performance margins. The preliminary design stage will entail indepth trade studies 
and assessments with higher-fidelity system/subsystem definition. 

In addition to the primary product (the concept), activities of the conceptual design stage produce 
other outputs that are carried forward with the concept or are retained as a record of the downselection 
process. A listing of these products is given in table 23. 
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Top-Level Subsystem Categories for Trade Options 


• Propulsion System 

• Control System 

• Materials System 


• Aerodynamics System • Structural System 

• Avionics System • Thermal System 

• Flight Mechanics/Trajectory Constraints 


Propulsion System 

• Liquid 

- RP-L0 2 

- LH 2 -L0 2 

- RP-Air Breathing 

• Solid 

• Hybrid 




Pressure Augmented 
Engine Cycle 


Flight Mechanics/Trajectory Constraints 

• Flight Mechanics 
- Staging 

• Single 

• Multistaged 

• Parallel Burn 

• Air Assist 

• Air Launch 


Aerodynamic System 

• Lifting Body 

* Control Augmentation 


Structural System 

• Main Frame 

- Composite 

- Metallics 

- Hybrid 




Casting 

Welding 

Fastener 


• Tankage 

- Integral/Conformal 

- Nonintegral 

- Lines 

• Internal 

• External 




Shape, Size, L/D 
Bulkhead Configuration 


Avionics System 

• Distributed/Centralized 

• Redundancy Level 

• Degree of Autonomy/Self Check 


Thermal System 

• Active 

• Passive 

- Metallic 

- Ablative 

- Reflective 

- Heat Sink 

- Insulation 



• Integral with Airframes 

• Nonload Path 



• Guidance loop Closure 

- Early 

- Deferred 

- Open 

• Disturbance Accommodation Approach 
-Wind Biasing 

• Generic 

• Short Term 

-Propulsion Performance 
Anomaly Accommodation 

• Trajectory Constraints 

- G Maximum Acceleration 

- Q Maximum Dynamic Pressure 

- a, p Pitch and Yaw Angle-of-Attack 

- Separation Attitude and Orientation 
-Thermal 

-Atmospheric Winds 

- Azimuths 

- Orbit 

-Mixture Ratio 

- Launching Sites 

- Special 

• Dynamic Pressure/Mach number 

• Thermal 


Material Systems 

• Metallic 
- Steels 
-AL’s 
-Ti’s 

• Composites 



Manufacturing Options 
-Casting 

- Extrusions 
-Welding 

- Fasteners 
-Milled 

• Chemical 

• Machined 


Figure 80. Conceptual design stage — options and ideas. 


Table 23. Conceptual design stage products. 


Establish Program Strategy/Philosophy 

• List of constraints (mandatory requirements) 

• List of preferences, criteria, and weightings 

• Uncertainty levels; e.g., 3o, for system and combination 
approach for survivable failure modes 

• Failure tolerance requirements; e.g., FS/FS/FO; engine(s) out 

• Verification philosophy; e.g., prototype/protoflight 


Generate Systems Concepts (Ideas) 

• System sketches; includes vehicle configuration, 
manufacturing process, and operations 

• Top-level discriminators 

-Performance criteria/constraints and margins 
- Derived criteria and margins 
-Weighting factors 


Evaluation of Alternative Concepts 

• For each concept 
-Point design 
-Sensitivities 
-Uncertainties 
-Margins 

• Concept validation provided by functional disciplines 

• Performance parameters for each concept 

• List of nonmatured technologies 
-Define TRL’s, cost, and time to maturity 

• Risk definition and mitigation 

-Estimate of risk levels and their consequences, 
Includes failure modes definition 

• Attribute matrix for each concept 


4.4.1.8 Managing To Ensure Proper Concept Selection. Proper concept selection depends on 
having the right skills, the right tools, excellent communication, and process leadership which enables the 
desired synthesis while avoiding pitfalls that can delay the process. Experience has led to the following 
guidance which is reiterated in the lessons learned section: 

• The right concept selection is critical. The large majority of life-cycle cost is locked in by the 
concept that is selected. 

• The best detailed design will not correct a flawed concept selection. 

• Put sufficient effort into front-end engineering (quality lever). 

• Ensure that options are fully explored, converging with successive refinement (greater detail) of 
concepts and requirements. 

• Pick a concept only after appropriate convergence, considering all the concepts; i.e., do not 
eureka the concept. 

• In early phases, discipline specialists must assess validity of sizing program results. Do not 
depend on sizing program alone. 

• Avoid concepts having too many technologies at low TRL’s. 
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4.4.2 Preliminary and Detail Design Stages 


Preliminary design takes the concept(s) that was downselected by the conceptual design stage and 
defines it in significantly more detail. Major trade studies are conducted to balance and specify the 
subsystems. System attributes of performance, weight, and cost are determined with good fidelity. The 
detail design stage continues the refinement process, detailing the system, subsystem, and component 
design, and producing the drawings and specifications necessary to go into manufacturing. 

Preliminary design and detail design follow much the same process in refining the design 
definition as better data are obtained from tests and analyses. Both stages proceed toward convergence in a 
series of design cycles having a typical basic pattern discussed in the following paragraphs. 

4.4.2.1 Design Cycles. A design cycle is a sequence of activities among the design functions and 
disciplines that produces a consistent set of subsystem definitions; i.e., where the designs of the structures, 
propulsion, trajectory, etc. work together and are not contradictory. The Space Shuttle had five design 
cycles (sometimes called loads cycles) and three or four abbreviated cycles to study special problems. The 
special cycles (sometimes called minicycles) arise when a phenomenon is not initially revealed by analysis 
or test and must be dealt with by design changes. Changes in operations are another means of dealing with 
design shortfalls; however, these usually entail increased operational complexity or constraints on launch 
availability. 

An example of a special minicycle is the Space Shuttle lift-off dynamics coupled with lift-off 
ignition overpressure. Not only did the complex multipoint dynamic constraint problem have to be dealt 
with (loads too high if not considered), but also the high overpressure energy at SRM ignition had to be 
accommodated by design changes to the vehicle hardware and the launch facilities (water suppression 
system). Many external tank protuberances, etc., had to be redesigned and qualified. 

Many design cycles must deal with a critical issue in a short period of time. The question arises: 
How do we know when a cycle or cycles are complete? Generally, there are two types of criteria: 

1 . The first criterion is task completion. Complete all the tasks in the process, and make appropriate 
design changes. It will take a given amount of time to accomplish each task sequentially, 
making use of parallel efforts where possible. The cycle is not over until all the tasks are 
accomplished. 

2. The cycle is not complete until all gates and criteria are met; in other words, the problem has 
been solved. Where it is clear that further refinement of the design remains to be done, or if 
other problems requiring a design cycle have surfaced, a new baseline is developed for the next 
design cycle, including sensitivity data and special discipline study results. 

It is not possible to quantify how many design cycles will be required. The complexity of the 
system and the evolving top-level requirements have an effect on the cycles required. The minimum 
number is around three: one each for PDR, CDR, and DCR. At DCR, the design cycle must include all the 
verified models, a gate for this cycle only. The Space Shuttle had five design cycles during Phase C which 
were called Integrated Baseline Vehicle Configuration (IB VC) I, II, HI, etc. In addition, minicycles were 
performed for — 
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• Overpressure (STS-1) 

• Aerodynamic problems (STS-1) 

• ET protuberances 

• Minicycles in engine design 

- Two-duct manifold 

- Wide throat combustion chamber 

- Advanced turbomachinery development 

• Space Station had three major cycles and several minicycles, such as: 

- Node gusset 

- Common berthing mechanism 

- Meteoroid/debris shields. 

Some think that with modem techniques the design can be accomplished in one cycle. Certainly 
that is desirable, but even with the most efficient approach, two cycles appear a minimum. Experience has 
shown that if you cut too much from the mainstream design effort on high performance systems, problems 
will occur, creating minicycles which end up extending the schedule and raising cost. The design cannot 
violate nature. Ensuring a realizable and consistent design with the current compartmentalization/ 
allocation approach requires iteration. 

4.4.2.2 Activity Sequence. The previous sections have dealt with various aspects and tasks of the 
design process, indicating activities sequencing. This section summarizes key elements of this sequence. 
In this document, the design sequence will be addressed primarily from the perspective of the aerodynamics, 
trajectory, G&N, control, structures, thermal design functions, and system design function. It will include 
propulsion and avionics at a summary level only. Also, interfaces with materials and manufacturing are 
shown without developing the specifics of those design functions. Propulsion, avionics, materials, and 
manufacturing can be expanded in detail similar to the above design functions, but this is beyond the scope 
of this document. 

A design cycle in either preliminary design or detail design follows the same basic sequence but 
with differing levels of detail and fidelity of input data. The activity sequence of the interacting design 
functions and disciplines is similar to that of the conceptual design stage which was illustrated in figure 77. 
The starting point, however, is the baseline design of the previous cycle, along with its sensitivities and 
supporting data. The first cycle of the preliminary design stage has as its starting point the output of the 
conceptual design stage. 

A number of activities can proceed in parallel and should do so where possible. However, some 
activities require as input the results from other activities and so must be accomplished sequentially. 

The following are the major steps in the activity sequence for a design cycle. The steps are 
illustrated on figure 81, which will be discussed at the end of this section. 

a. From the previous cycle, collect and review the requirements and constraints; the philosophy, 
procedures, and criteria; the baseline design, including sensitivities and supporting data; and 
any identified problems or design shortfalls. Determine the direction of modification for the 
upcoming design cycle. The systems plane, in consultation with the other design functions, 
allocates requirements and constraints to the design functions, reflecting the desired modifications. 
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b. Propulsion provides propulsion system characteristics, based on its design cycle and on the 
above allocations. 

c. Structures design modifies the vehicle configuration, directed toward resolving problems of the 
previous cycle’s baseline or expanding the level of detail of its definition. 

d. Aerodynamics provides updated aerodynamic forces, moments, and pressure distributions based 
on updated configuration, wind tunnel tests, and analyses. Aeroelastic stability is assessed to 
specify stiffness requirements or trajectory constraints on dynamic pressure. 

e. Ascent trajectory/performance analysis is conducted to determine the payload performance of the 
vehicle, including margins, reserves, and fuel bias, and to determine the flight path of the vehicle 
under constraints developed at both the systems level and the discipline level. Typical constraints 
levied in order to have a tractable and reasonable design include at least the following: 

• Targeting points for staging and insertion 

• Abort/failure targets for engine out 

• Dynamic pressure for aeroelastic ity and loads 

• Axial acceleration for human passenger and payload limits 

• Angles of attack for loads 

• Thermal constraints. 

The trajectories can be modified for operations, within limits. 

f. Reentry and recovery trajectories are determined, considering dispersions in initial conditions 
and variations in environmental and vehicle parameters. 

g. Design reference trajectories are generated for control, loads, and thermal analyses. These 
trajectories are chosen to represent potential operational missions, attempting to envelop the 
design parameters to maximize a variable such as a load indicator, while maintaining a physically 
realizable trajectory. The parameter combination for a reasonable maximization of the desired 
variable is determined by a judgment choice, guided by numerous dispersed trajectory runs. 

h. Basic control response analysis is performed for the design reference trajectories plus parameter 
variations to determine the vehicle’s response to winds and other forces during high-q ascent 
flight and the transition response during reentry. This basic simulation is also used to determine 
the control logic for stabilizing and controlling the vehicle. The control logic is adjusted to meet 
additional constraints of load indicators like q-alpha and q-beta, control authority limits, etc. 

i. Loads indicator models combine the control responses with other information about the vehicle, 
trajectories, and flight events to produce estimates of structural loads at pertinent vehicle 
locations. 

j. Thermal indicator models use trajectory, control response, and configuration information to 
produce estimates of heating at critical locations on the vehicle. 
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k. Approximations of design capability corresponding to the loads and thermal indicators are 
determined from the existing design description. 

l. The loads and thermal indicators are used to provide estimates of the structural and thermal 
system demand that are compared with the approximate design capabilities to determine 
adequacy or impact. This information guides decisions on potential further design changes. 

m. In addition to these activities that are focused on system performance, the cost, reliability, 
operability, safety, and other attributes of the design are assessed and compared with requirements 
and allocations. 

Also fed by the design reference trajectory outputs are detailed analysis and design activities 
that constitute the indepth determ ination of the design, and are the basis of the approximations used in 
items i, j, and k above. These include the following: 

n. G&N systems for each flight phase are synthesized and analyzed, balancing the magnitude of 
off-nominal dispersions and performance loss with the accuracy (cost, complexity) of the 
sensors and software requirements. Abort and contingency targeting are a major consideration. 

o. The structural dynamics discipline generates dynamic models of the elastic structure for use in 
control and loads analysis. 

p. Control systems are synthesized and analyzed in detail, including all pertinent nonlinearities 
and effects. Sensor and actuator requirements are identified and updated in coordination with 
avionics. 

q. Making use of the dispersed response data and the chosen method of combining uncertainties, 
consistent vehicle loads are determined for each major loading event: 

• Transportation 

• Lift-off 

• Ascent max q 

• Ascent max g 

• Docking 

• Reentry 

• Landing and recovery. 

Iterations with other disciplines may be necessary to bring the loads to within an acceptable range, 
through changing the aerodynamics, trajectory, control, parameter variation approach, criteria, etc. 

r. Acoustics/overpressure environments are determined and applied as loads to the structural 
elements where this high-frequency loading is significant. The vibroacoustic environment is 
determined for components and is converted to component design and test criteria. 

s. Aerothermodynamic and plume heating environments are determined consistent with the 
updated design reference trajectories and configuration. 
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t. Thermal analysis and design can be done in parallel with loads analysis. Induced environments 
are determined from aerothermodynamics, plume heating, propulsion system inputs, avionics, 
and other on-board system inputs. Based on these induced environments and the natural 
environments, designs are accomplished for TPS’s, cryogenic and propellant insulation, and 
TCS for components and compartments. These design activities interact strongly with other 
design functions and disciplines. Material selection for TPS and insulation systems is crucial 
and, in conjunction with temperature requirements of the vehicle systems, provides the basis for 
sizing the TPS and insulation. Designing active and passive TCS likewise requires selection and 
sizing of materials and components. 

u. Based on the thermal systems designed above, structural temperatures and gradients are 
calculated, and thermal environments of components and compartments are determined. As in 
other systems, the analysis is part of the iterative design process. Outputs to other design 
functions and disciplines are made after convergence of the thermal design. 

v. Stress and life analyses are performed for the baseline configuration, using the loads and 
thermal data provided. Stress fields and deflections are determined and compared with 
specified criteria. Deflection and buckling stability are analyzed. Fracture and fatigue analysis 
are performed to obtain cycles and time to failure and to develop fracture control plans for 
fracture critical parts. The level of modeling detail is set to be appropriate for the maturity of the 
design cycle being analyzed. If criteria are not met, either the environments must be reduced or 
the structural design must be changed. 

w. Structural design works closely with the stress and durability disciplines to identify design 
modifications to correct structural strength or life shortfalls. Meanwhile, structural design 
receives inputs from and interacts with the other design functions, including thermal, propul- 
sion, avionics, and auxiliary subsystems. The structural design is modified as required to 
accommodate these other subsystems as their designs evolve. In this role, structural design has 
a primary packaging and integrating function. The structural design as modified becomes the 
baseline for the next cycle. If modifications are complete or are essentially complete (as 
indicated by successfully meeting criteria and interfaces), drawings and specifications are 
finalized. 

In parallel with the summary-level and detailed discipline analyses and design activities 
described above, there are special analyses of specific phenomena that must be assessed and designed for, 
but which are handled separately from the primary design loop. These typically are stability or transient 
phenomena such as flexible mode control stability, pogo stability, aeroeleastic stability, separation 
transients, docking transients, etc. Provision or “headroom” is made for these effects in the primary design 
loop, including appropriate margins. Examples are shown in the next four items. 

x. Control stability analyses are conducted using elastic body dynamics and slosh dynamics 
models. These produce slosh baffle requirements and algorithm requirements for stabilizing 
elastic and slosh modes. Confirming analyses are run with the baffle models and stabilizing 
algorithms simulated to confirm satisfactory margins. 
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y. Aeroelastic stability is assessed by structures, aerodynamics, and (if pertinent) control. The 
design is moved away from any aeroelastic stability limits, allowing adequate margins. 

z. Pogo stability analyses are run to determine the requirement for a pogo suppression system. 

aa. Special transient events are assessed, including liftoff and separation clearance, docking 
response, landing or recovery response, etc. Results of these assessments produce require- 
ments on the vehicle design and its interfacing ground systems. 

Completing the design cycle involves the following activities: 

bb. Concurrent with the above activities are related design and analysis activities that are influ- 
enced by the primary design cycle but are less coupled to it. These include landing and 
recovery systems, pyrotechnic systems, compartment venting design, life support systems (if 
applicable), and breakup/disposal analysis. 

cc. Also concurrent with the above are the major propulsion, avionics, materials, and manufactur- 
ing design activities which can be described in similar detail to the items above (beyond the 
scope of this document). They interact with the other parts of the system design to ensure 
compatibility. 

dd. All subsystems develop verification plans, production plans, and operations plans. Verification 
of analysis models and development testing of the designs constitute an important part of the 
design maturation. 

ee. The end of the cycle produces the baseline design and sensitivities to begin the next cycle or, if 
complete, produces the drawings and specifications for entering the production stage. 

ff. The hardware and software are produced and verified, involving many components and 
process steps. 

gg. Operational procedures and constraints are developed from the above activities, drawing heavily 
on the analysis and verification program to ensure that the vehicle maximizes its operational 
capability while not violating safety constraints. 

The activity sequence discussed above has a multiplicity of facets. A clear visualization of the 
design sequence can be illustrated with the application of the various categories of activities and/or models 
delineated in section 3.5. Recall, these models consist of a generalized model, specialized models, and 
discipline specific models. Shown in figure 8 1 are the design process activities (i.e., activities a through gg) 
and their association with the three models. This illustration indicates where the various activities fit relative 
to the models, as well as how the models are applied after the initiation of a design or a design change. 
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Specialized Models 



Figure 8 1 . Design process activities interactions. 


Subsequent to initiation, the characteristics of the trajectory are determined using the generalized 
model. It can be seen that properties of the trajectory (i.e., g ) drive the specialized models and the disci- 
pline specific models. The major outputs from the discipline activities are drawings/specifications, the 
design capability, and indicator models. The indicator models are included in the generalized model to 
assess the loads and thermal demand versus the capability of the design. In a parallel fashion, results (e.g., 
stability determination) from the specialized models are also compared to the capability. When the total 
demand is within the capability and has acceptable margins, the design is approved and the hardware goes 
into the production, verification, and operational stages. 

For every iteration of the design, all primary subsystems are assessed (see bb and cc). Since many 
subsystems are coupled to the vehicle system (e.g., propulsion, avionics, etc.), the impact of their interac- 
tions is required to be evaluated. This evaluation is accomplished through an activity sequence similar to 
that of the vehicle activity sequence. For those subsystems, a figure parallel or similar to figure 8 1 could be 
developed to illustrate their specific design cycle activity sequence. It would include a generalized model 
that describes the subsystem attributes, and the associated specialized models and discipline models. 

While figure 8 1 has been developed to illustrate launch vehicle design, a similar illustration could be 
developed for operations. For instance, after a payload is selected, similar vehicle generalized model is 
applied to assess the impact of the payload on the vehicle and vice versa. Assuming that the demand meets the 
capability, the generalized model is applied to assess the operational constraints for flight; e.g., day-of-launch 
wind limits. 
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5. PROCESS IMPROVEMENT 


The major focus of this document is to characterize the launch vehicle design process. This 
characterization can then serve as a baseline to identify and evaluate improvements on the current process. 
As discussed in section 1.1, there is a clear need for low cost, high performance, reliable launch systems. 
NASA and the aerospace community must attain significant advances in launch system technologies in 
order to meet this need. 

There are two categories of technologies applicable toward this objective: (1) hardware/software 
technologies, and (2) design process technologies. The first category includes the obvious technologies of 
new materials, new propulsion concepts, etc., that address the physical aspects of launch systems. It is 
essential that these technologies be advanced, and major efforts are underway toward this objective. The 
second category recognizes that the conduct of the design process is itself a technology that must be 
advanced in order to achieve more capable and cheaper systems. 

5.1 Vehicle Hardware/Software Technologies 

This category deals with the different ways of optimizing the effects of the physics of the problem as 
was so well expressed by Rick Fleeter*- when he said that the energy available in splitting the molecules 
(propellant) was just sufficient to overcome gravity to get to orbit. Technologies in this category range from 
advanced energy transfer and propulsion concepts to new structural materials and alternative avionics 
systems. These areas must be pursued to achieve the needed major advances in cost, reliability, and performance. 
Several such technologies are being explored and matured; new technologies need to be identified. 

5.2 Design Process Technologies 

In addition to essential advances in vehicle hardware/software technologies, the design process 
itself must be improved. The efficiency and effectiveness of the process can be improved by application of 
the experience-based principles and lessons learned identified in section 7. In addition, the technology of 
the design process itself must be improved. This is the subject of the remainder of the section. 

It should be noted that the ideas and suggestions presented here are by no means all inclusive. They 
are just ideas and suggestions that are intended to stimulate thought and action toward improving the 
design process. 

5.2.1 Design Process Shortcomings and Potential Approaches for Improvement 

An examination of the current design process and its history indicates areas of shortcomings, 
including at least the following: 

• The process is fragmented and not well organized, producing inferior designs. 
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• There are deficiencies in the ability to predict (model) design performance, especially cost, 
reliability, and operability. 

• Synthesis is an idea-driven process that may miss promising concepts if the designer stays within 
his experience “box.” 

• There is low confidence in the conceptual design stage where a high percentage of the cost is 
locked in. 

• The design process has difficulty in handling the vast quantity of required data and information 
and in providing necessary visibility to all involved. 

New design process technologies should be sought to address the above deficiencies. Approaches 
for high leverage improvement include — 

• Reduction of process fragmentation; more seamless design in 

— Subsystem, design function, and discipline function compartmentalization 
— Design for all mission events and design stages 

• Improved modeling and knowledge base, especially for cost, reliability, and operability 

• More direct synthesis approaches 

— Conversion of requirements to concepts and designs 

- Ideation and visualization of design space 

• Improved conceptual design process 

- Better synthesis and higher fidelity models 

- Scaleable representations that mature into subsequent design stages 

• Means for efficiently conveying and displaying necessary design information to all participants. 

5.2.2 Evolutionary Improvements 

There are many options for fine tuning the present design process. Several are discussed in the 
following paragraphs. 

5.2.2.1 Requirements and Criteria. The tendency in aerospace has been to place all our lessons 
into the form of requirements and criteria. This takes many forms. Analysis of failure modes is replaced by 
various detailed criteria instead of understanding and preventing failures. The requirements/criteria are so 
stated that many times they dictate the design and leave very little room for innovation and creativity. 
Required documentation, procedures, etc., are often very excessive. Currently in the Space Station program, 
NASA is insisting on excessive documentation and traceability of not only hardware but also all analysis, 
test, etc. No use or very limited use is being made of electronic databases, etc., to meet the documentation 
requirements. A key task for fine tuning the system is to strongly work the requirements and criteria, 
making the system efficient and allowing for the interjection of creativity and innovation. 
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5 . 2.22 Design for Simplicity. The “Experienced Practitioner” survey (section 7. 1 ) has many references 
to designing for simplicity. There are many measures of simplicity that can be used as guidelines: 

• Simple load paths 

• Number of functions 

• Number of parts 

• Complexity of functions 

• Number of turnings 

• Number of steps/offsets 

• Etc. 

This is only a partial list. Pugh in Total Design 3 and other publications emphasize designing 
structures by load lines/paths. Others illustrate the approach in different ways. Present launch systems are 
very complex. Future systems require simplicity. The key task is to study simplicity and implement ways 
of incorporating it into design. 

5 . 2.23 Improved Modeling Tools. Initiatives are in progress to improve modeling and simulations 
related to essential aspects of the design process. These include: 

• High fidelity simulations for virtual flight 

• More granular operability and maintainability modeling 

• Embedding more probabilistic methods into the design process 

• Bottoms-up cost modeling for smoother interface with current top-down cost models 

• Multidisciplinary modeling using CAD geometry as basis 

• Rapid modeling techniques to enable a greater number of sensitivity analyses. 

52 . 2.4 Integrating Various Discipline Analyses Into Single or System Tasks. The process today for 
structural design is for the dynamic specialists to first ran a load analysis and then pass the loads to stress analysts 
for strength and durability analyses. These results are then passed to the designer for design changes, etc. Instead 
of sequential analysis, a better method would be multidisciplinary analysis. At various stages of the design, the 
multidisciplinary analyses take different form. This process is more efficient, and confidence in the results 
increases, without putting any discipline out of business. Activities directed toward this end are — 

• Load transformation matrices 

• Stress transformation matrices (allow time consistent stresses) 

• Integrated trajectory, control, and loads 

• Thermal transformation matrices 

• Improved sizing programs 

• Combining multidisciplinary equations into a single set and developing codes for the integrated 
system 

• Applying design of experiments for analysis and test. 
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5.2.3 Revolutionary Advances 

As noted in the previous section, evolutionary improvements in the design process should be pursued 
as an immediate means of increasing process efficiency and effectiveness. However, as discussed in section 
1.1, revolutionary changes are required to achieve major advances in launch vehicle cost and 
capability. 

The following discussion is intended to stimulate thinking and ideas toward needed revolutionary 
advances. Revolutionary changes in design process technology can address the two general problems with 
current design process: (1) The current process does not arrive at the best design because of its many 
compartmentalization/reintegrations, its ad hoc experienced-based synthesis, and its fragmented analysis 
of limited fidelity; and (2) the process is too long and costly. 

The ideal design process would be an automated process that converts requirements into an opti- 
mal design in a single step. Achieving such an approach lies in the distant future but should be the guiding 
star target for our efforts in the interim. Until the ideal one-step approach is achieved, we will need to seek 
revolutionary advances in the multistep process that is characterized by compartmentalization, synthesis, 
analysis, and reintegration. We can consider advances in each of these areas. 

5.2.3.I. Compartmentalization/Reintegration Technology. Generically compartmentalization/ 
reintegration technology currently is applied, not only to vehicle system/subsystem compartmentalization, 
but also to design functions, disciplines, requirements accommodation (i.e., performance, cost, etc.), 
operational events (lift-off, atmospheric flight, reentry, etc.), and stages of the program. Technology 
advances are needed to unify as many of these compartmentalized areas as possible into a seamless whole. 

5.2.3.2 Synthesis and Design Update Technology. Currently, any design synthesis or design 
update depends on the designer’s ideas and experience base on an ad hoc basis. Possible approaches to 
technology leaps in this area include idea stimulus approaches; use of artificial intelligence and 
knowledge-based systems to convert designer’s judgments and rules of thumb into algorithms; techniques 
for visualization of the design space; multidisciplinary optimization; and automated synthesis or inverse 
engineering, using, for example, approaches like structural shape and topology optimization. 

5.2.3.3 Analysis Technology. Potential advances in analysis technology might be pursued along 
several fronts, including combining discipline analyses, major advances in fidelity, inclusion of life cycle 
metrics, and full probabilistic design enablement. 

5.2.4 Interactive Information and Communication System 

As a design proceeds through the various stages from the concept stage to the operational stage, 
there is a need for an interactive information and communication system (I 2 CS). The system would consist 
of various computerized and electronic tools to facilitate all aspects of the design process. These hardware 
and software tools could improve the information flow, interactive team communications including those 
from remote locations, multidisciplinary model implementation, etc. Specific examples of various 
computerized tools would consist of the following: 
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• A residence and/or placeholder for the design description and specifications, associated 
attributes, ICD’s, and supporting data (this tool could be based upon the design process 
characterization model along with the NxN and Ixl diagrams) 

• A real time interactive communications system 

• A management related information system (this tool would include the WBS, cost spending 
profiles, allocations, reserves, schedule, etc.) 

• An electronic mock-up with fidelity consistent with the design stage 

• A flight performance simulation with fidelity consistent with the design stage that displays key 
performance indicators versus flight time 

• An advanced interactive multidisciplinary optimization systhesis system that can search for 
architectures per given requirements and constraints but driven by optimization algorithm 

• A virtual reality design system that can focus on the vehicle system, element, subsystem, or 
part where the design participants can assess the realization of their design decisions in real time 

• An interactive synthesis tool with “design-to” models that include performance, cost, 
reliability, safety, operations, etc. 

In addition to the above examples there are certain features that are required to enable these tools. 
Typical examples of these features are as follows: tools must be secure, configuration controlled, 
accessible by all participants and compatible with industry counterparts; system permits simultaneous 
viewing and communications by multiple users interactively; framework implements compartmentalization 
and reintegration with residence and/or placeholders for all design related data and includes prompts, 
impact assessment, traceability, etc.; hypertext characteristics for data, graphics, etc.; action items and 
tracking; trade study tracking; scalable for growth; seamless file transfer; searchable and interrogatable; 
and platform insensitive. Other features would also include e-mail, telephone, video conferencing, and 
manufacturing and testing real time video acquisition. 

The I 2 CS design tools are needed to improve the design process efficiency and effectiveness. This 
system will provide the designer the unique capability to achieve the best real-time design within the 
performance, cost, reliability, etc., requirements and constraints. It is imperative that the requirements for 
the I 2 CS design tools be developed by the STS designers in collaboration with the tool developers. While 
much of the technology needed for I 2 CS exists currently, implementation of the system would provide a 
potential revolutionary improvement in the design process. 

The potential improvements listed above can apply to any design stage. Noting the high leverage 
effect of the conceptual design stage, particular attention should be given to technologies that enable selection 
of the correct concept. Discovering and developing revolutionary design process technologies are essential 
ingredients in meeting the mandate for major improvements in launch cost, capability, and schedule. 
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6. ILLUSTRATIONS OF PROCESS 


This chapter illustrates aspects of the design process using historical examples. An overview of the 
Space Shuttle conceptual design process and subsequent Phase C configuration cycles is given in 
section 6. 1 . Section 6.2 illustrates technical integration by describing the design process for flight mechan- 
ics with a loads modeling example drawn primarily from Space Shuttle history with some comparisons to 
Satum/Apollo and X-33. 

6.1 Overview of Space Shuttle Design History From Phase A Through Phase C 

When examining the design process for launch vehicles, it is instructive to consider the history of 
past launch vehicle design. This section provides an overview of the Shuttle concept selection and major 
configuration design modifications (Phase A through Phase C) which illustrates the magnitude of its 
conceptual design process and the extent to which the design selection was determined by external 
considerations, such as political, budgetary, etc. Much of the material comes from the excellent book 
Space Shuttle, The History of Developing the National Space Transportation System . 13 

6.1.1 Political Activities 

Political considerations shaped not only the existence of the Shuttle program but also the form of 
the vehicle design itself. These directions and constraints resulted from national needs and priorities, the 
economic environment, and multiple government agency roles and interests during the 1969-1971 time 
frame (see table 24). 

In 1969 President Nixon formed a Space Task Group composed of senior NASA and Air Force 
personnel and headed by Vice President Agnew. This group was charged with identifying the Nation s next 
directions in space exploration. They recommended three ambitious options including a lunar station and 
Mars exploration, the least ambitious option being a $5B per year program for both an Earth Space Station 
and a Space Shuttle. Nixon rejected all three options as being unaffordable in the economic environment of 
the time. 

Meanwhile, NASA formed a Space Shuttle Task Group (SSTG) led by Leroy Day which defined 
classes of Shuttle missions and recommended trade studies among broad vehicle characteristics such as 
reusable versus expendable stages, categories of engines, cross-range capability, payload size, launch 
orientation, and series versus parallel bum. The SSTG defined three classes of vehicles: Class I reusable 
orbiter/expendable boosters; Class II — stage-and-a-half expendable tanks; Class III reusable 
two-stage-to-orbit (TSTO). Class III was the SSTG’s first choice. 

In 1970, NASA Administrator Paine and Secretary of the Air Force Seamans established a NASA/ 
Department of Defense (DOD) STS Committee. The White House rejected the resulting proposal for a 
Shuttle program (without a Space Station). 
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Table 24. Space Shuttle history — political activities. 


CONCEPTUAL DESIGN STAGE PRODUCTS 

February 1969 

February 1969 

January 1970 

• Space task group formed by Nixon 

• Team: 

- Spiro Agnew 

- Senior NASA and Air Force personnel 
■ Recommendations: 

- $8-10 B/yr Lunar Space Station, 

50 person Earth Space Station, 

Mars Exploration 

- $8 B/yr 50 person Earth Space Station, 
Mars Exploration 

- $5 B/yr Earth Space Station 
and Space Shuttle 

• Result: 

- Nixon rejected ail three proposals 

- NASA had to propose 

• Space Shuttle first step 
to Space Station 

* SSTG 

• Team results: 

- Leroy Day (Leader) 

- Six missions defined 

• Logistical support for 
for Space Station 

• Service low Earth orbit (LEO) satellites 

• Propellant delivery to LEO 

• Satellite service 

and maintenance (LEO) 

• Delivery of LEO payloads 

• Short manned missions 

- Trade studies recommended 

• Reusable vehicle 

• Pilot fly back versus expendable 
booster 

• Off shelf versus new engine 

• 230 miles versus 1 265 cross- 
range capability 

• 15 K versus 50 K payload 

• Vertical versus horizontal launch 

• Sequential staging versus parallel burn 

- Defined classes of vehicles 

I Reusable orbiter/expendable 

boosters 

II Stage-and-half expendable 
tanks 

III Reusable TSTO 
(SSTG choice) 

• MSC started in-house 
STS Design 

- Concerned ovenf>B RFP 
requirements 

- 8 x 30 ft payload bay 

- Payload 10 K to 15 K 

- Class 111 

- Cross range 200 mi 

- Orbit 310 mi, 55° 

- 30 flights/yr 

- Cost $5.8 B 

September 1970 

February 1971 

September 1971 

• NASA administrator (Paine)/ 

Secretary of Air Force (Seamans) 
Established NASA/DOD STS committee 

• Shuttle project rejected by White House 

• NASA Administrator (Fletcher) 

- Significantly reduced cost 

- DOD committed to use it 
for all launches 

• Must meet all DOD requirements 

- STS was first program subject to 
formal economic analysis 

and requirements by OMB 

- STS must be the only launch vehicle 
during the 1980’s and later 

- Space Task Group (STG), DOD, 
Presidential Scientific Advisory 
Committee, NASA, American 
Institute of Aeronautics and 
Astronautics (AIAA) — all support 
STS development 

- DOD requirements 

• Payload bay 15 x 60 ft 

• Payload 40,000 polar orbit 
60,000 due east 

• Cross range 1,100-1,500 miles 
(issue: reentry heating) 

- DOD, CIA, NASA, etc. supported 
Shuttle as the only launch vehicle 

• DOD did not provide dollars 
but — 

- Contributed facilities for 
orbiter construction at 
Palmdale 

- Presented united front with 
NASA to Congress 
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New NASA Administrator Fletcher in 1971 determined that keys to acceptance of a Shuttle 
program were to significantly reduce cost and obtain broad support for the program from all involved 
Government agencies and organizations. DOD committed to use the Shuttle for all of its launches provided 
that it meet all DOD requirements. The necessary support was obtained from the numerous agencies, and 
a commitment was made that the Shuttle would be the only launch vehicle developed in the 1980 s. The 
Shuttle program was the first of its kind to be subjected to formal economic requirements by the Office of 
Management and Budget (OMB). The DOD did not provide funds but contributed Palmdale facilities for 
orbiter construction. With these agreements, the agencies presented a united front with NASA to the 
Administration and Congress, enabling the acceptance of the program. 

6.1.2 STS Phase A 

Phase A of the Shuttle program began before the previously discussed political activities, and had 
its foundation in reusable vehicle studies undertaken during the history of spaceflight (see figure 82 and 
table 25). In 1968, MSFC and the Manned Space Center (MSC) (JSC predecessor) issued a joint request 
for proposal (RFP) for integral launch and reentry vehicle concept studies. Five awards were made: 
General Dynamics (GD), McDonnell Douglas (MAC-DAC), Lockheed, Martin Marietta (MM), and North 
American Rockwell (NAR). A 4-month study led to NASA continuing funding for all of the four except 
Martin Marietta, who continued work with internal funding. The Air Force provided oversight by the 
Aerospace Corporation, plus in-house work on stage-and-a-half concepts by Flight Dynamics Laboratory 
(FDL). The five NASA contractors focused on Class III vehicles (fully reusable) and spent 200 man-years 
of effort, along with extensive aerodynamic, materials, and structural testing. Categories of orbiter 
configurations were lifting body (rejected), variable wing (rejected), straight wing (proceeded to Phase B), 
and delta wing (proceeded to Phase B). In addition to these concept studies by industry and government, a 
series of technology working groups were chartered to develop the key technologies required (see fig. 83). 
Each of these working groups had extensive activities and significant expenditures. 



Figure 82. Space Shuttle history — example Phase A configurations. 
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Table 25. Space Shuttle history — Phase A. 


Year 

October 1968 

February 1969 

October-December 1969 

Requirements 

Integral launch and reentry 
vehicle Joint RFP (MSFC 
and MSC) 

NASA concept 
study 

4>A results: 

Effort 

• Focus 

Cost and safety 


• 200 man years 

• Pid (K#) 

5-50 


• Extensive aerodynamic, 

• Orbit (miles) 

115-345 


materials, and structural 

- Baseline 

• Cross range (miles) 

300 

450 


testing 

• Engine 

Contractors 

MSFC 


Four baselines 

• Straight wing (Phase B) 

• Delta wing (Phase B) 

• Variable wing (rejected: 
complexity, etc.) 

• Lifting body (rejected: 
packaging, etc.) 

Configurations 


GD 

GD (MSFC) 

• IK (2) 


MAC-DAC 

MAC-DAC (LARC) 

• III (12); $5.9B; 21 months $67/# 


Lockheed 

Lockheed (MSFC) 

• III + 11 (4); $5.5 B; $25/# 


MM 

MM In-house ($) 

• III (25) 


NAR 

NAR (MSC) 

Air Force Space Division 

• Aerospace oversight 
of NASA 

• FDL (stage + 1/2) 

• III (1 + Opt); 52 months 


Balancing Act Between Requirements and Design Leads to Class III "| 



• Uncertainties 
-Winds 

- Thrust Vector Misalignment 

- Rigid Body Aerodynamic Coefficients 

- Thrust 

1 sp 

- Weight 

- Fuel Residuals 


1 — Others 

• Develop Key Technologies 


Figure 83. Space Shuttle history — Phase A concept studies and groups. 




6.1.3 STS Phase B 


The convergence of concepts during Phase A led to the issuance of a Phase B RFP in 1970 for a 
fully reusable two-stage vehicle (see fig. 84). Major requirements of the RFP are listed in table 26. Two 
orbiters were to be developed: one capable of 230 miles cross range and the other capable of 1 ,726 miles 
cross range. Go-around capability was required for both orbiter and booster, which implied the use of 
air-breathing engines on both vehicles. Two teams were awarded contracts: MAC-DAC/MM and 
NAR/GD. Two months later, requirements were revised to increase payload from 15,000 to 25,000 pounds 
and to specify JP-4 fuel for the air-breathing engines (safety issue). During the Phase B activities, both 
teams matured their designs through trade studies, arriving at low and high cross-range orbiter 
configurations with a common booster. The orbiters had hot-structure TPS s and two main engines each. 
Two engines provided best performance and lowest cost but later gave way to the three-engine 
configuration to better provide abort capability with engine out. The baseline Phase B configurations are 
shown in figure 85. 


Year 


July 1970 

RFP 


Requirements See Table 26 


Contractors 


A. *MSC-Responsible 

1. MAC-DAC and MM 

2. NAR and GD 


September 1970 


December 1 970 May 1 971 

• Revised Requirements 


Results Results 

- Payload 15-25 K 





- Fuel (JP-4) 





- Pressurized Payload Bay 





• Technology Assessment 





General Area of Concern: 

Cost in ($): 




Aerothermodynamics 

3,715,000 




Dynamics and Aeroelasticity 

5,740,000 




Propulsion 

18,130,000 




Structures/TPS and Materials 

51,745,000 




Biotechnology 

1,960,000 




Integrated Electronics 

8,355,000 




Operations and Maintenance 

2,215,000 





-*A-1 

A-2 


1 

1 5 x 30 Payload Bay 1 5 x 60 payload bay 



15 K 

LCR-46 K 




HCR-20 K 



2 Engines + Turbofans 2 Engines and Turbofans 



2 Configurations 2 Configurations 



MAC-DAC— Orbiter NAR— Orbiter 



MM- 

-Booster GD— Booster 



B. MSFC— Alternate Space 
Shuttle Concepts (ASSC) 

1. Chrysler 

2. Lockheed 

3. Grumman/Boeing (MSC) 


Lead Center Concept Developed 
- MSC Integration of Shuttle Activities 
• MSFC Responsible for Propulsion 


1.SST0 

2. Stage and a Half 

3. Stage and a Half 

- External LH 2 Tank 

- 3 SSME T s 

- $6.7 Billion 


Figure 84. Space Shuttle history — Phase B. 


177 



Table 26. Space Shuttle history — Phase B. 


Phase B Program Requirements 

Requirements Levied by Various NASA Centers 

The shuttle shall be a fully reusable two-stage vehicle 

The integrated vehicle shall be launched vertically 
and landed horizontally 

The initial operational capacity shall be in late 1977 

The reference mission shall be a 310-mile 55° inclination 
circular orbit from a launch site located at 28.5 ° north 
latitude (Kennedy Space Center) 

The payload bay shall have clear volume 15 ft in 
diameter by 60 ft in length, with a reference mission 
capacity of 15,000 lb 

Two orbiters shall be developed: one capable of 230 miles 
and the other of 1 ,726 miles crossrange 

The mission duration (from lift-off to landing) shall be 
7 days 

The booster and orbiter shall have a go-around capability 
during landing operations (basically implying the use of 
air-breathing engines) 

Launch rates will vary from 25 to 75 per yr 

Total turn around time from landing to launch shall be 
less than 2 weeks 

Both elements shall provide a shirt sleeve environment 
with trajectory load factors of less that 3G 

A 43-hr turn-around capability shall be provided for 
rescue missions 

All subsystems, except primary structure and pressure 
vessels, shall be designed to fail-operational after failure 
of the most critical component, and to fail-safe for crew 
survival after failure of the two most critical components. 

Each element (orbiter and booster) shall have a two-man 
flight crew and be flyable under emergency conditions 
by a single crewman 

The stages shall be capable of positive separation without 
the use of special separation rocket systems of the type 
employed on Saturn 

In-flight refueling (subsonic or supersonic) shall not be 
used to meet design mission requirements 

The booster and orbiter shall be capable of pilot- 
controlled landings under FAA category-2 conditions 

The vehicle shall incorporate on-board provisions to 
quickly and easily place the vehicle in a safe condition 
following landing to permit crew and passenger egress 

There shall be no propellant cross-feed between elements 
(booster and orbiter) 

The vehicle elements (booster and orbiter) shall be 
capable of landing on runways no longer than 10,000 ft. 


While a fully reusable two-stage concept was the clear choice for lowest operational cost per flight, 
it became apparent that concurrent development of both an orbiter and a booster vehicle would be 
expensive. Peak-year development funding was becoming a concern. Addressing this issue, alternate Space 
Shuttle concept (ASSC) studies were initiated to look at alternatives to fully reusable two-stage concepts. 
Chrysler, Lockheed, and Grumman/Boeing studied single-stage-to-orbit (SSTO), stage-and-a-half, and 
external fuel-tank concepts. These studies provided the groundwork for future program decisions. 
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Orbiter: 


Booster: 


Orbiter: 


Booster: 


Two 415K Engines 
Four 18K Turbofans 

Two 415K Engines 
Ten 18K Turbofans 
in Canards 


Two 415K Engines 
Four JTF22B-2 

Two 415K Engines 
Four Turbofans 


Figure 85. Space Shuttle history — Phase B baseline configurations. 


6.1.4 STS Phase b' 


In 1971, OMB informed NASA to expect no budget increase in the next 5 years. At that time, the 
total NASA budget was $3.2B, with no more than $1B per year being allocated to Shuttle development. 
The Phase B fully reusable two-stage configurations required a development cost of $10B, peaking at an 
annual cost of $2B in some years. The budget constraints forced an extension of Phase B, designated 
Phase B , to search for ways to deal with the budget limitations (see table 27). 

Sacrificing lowest operational cost in order to obtain lower development cost, NASA endorsed a 
variation of stage-and-a-half which moved the fuel tanks outside the orbiter and also used expendable 
boosters. The contractor groups were expanded from the two Phase B teams by the addition of Lockheed 
and Grumman/Boeing from the ASSC studies, and the teams were told to reevaluate their proposals with 
requirements for using the MSC “040” orbiter, external tanks, and three main engines. Examples of 
Phase B" configurations are shown in figure 86. 

6.1.5 STS Phase B" 

At the end of Phase B\ development cost projections had been reduced significantly but were still 
too high (see table 28). An extension was provided to further study booster configurations, including 
recoverable liquid boosters and solid boosters. A major issue was whether the orbiter main engines would 
bum in parallel or in series with the booster. In December 1971, parallel bum was adopted, and abort 
SRM’s were added. Total development costs were now estimated at $5.8B. NASA further estimated that 
use of solid boosters would save $700M in development although carrying more operational costs and 
unknowns. In March 1972, NASA adopted solid boosters to go with the external tank and three-engine 
orbiter, entering Phase C with a configuration basically similar to today’s Shuttle, as shown in figure 87. 
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Table 27. Space Shuttle history — Phase B'. 


May/June 1971 

September 1971 

October 1971 

• 0MB informs NASA no budget 
increase for 5 years 

TSTO (<(>B) Shuttle development 
cost $1 OB with peak of $2B 
some years 

Contractor teams expanded 
to four: 

- MAC-DAC and MM 

- NAR and GD 

- Lockheed 

- Grumman and Boeing 

B' ended 

Proposed total NASA budget 
was $3.2B for 1972 

Only $1 B/yr for STS 

MSC considered external tanks 
first time in their in-house studies 

- 15x30 payload bay 

- 20 K payload 

- 4 engines 

- Internal lox tank 

Requirement: 

Reevaluate proposals 

- MSC— 040 Orbiter 

- External tank 

- Three high-pressure 
chamber main engines 


NASA endorses variation of stage 
and a half (called semi-reusable) 

- Some configurations developed 
in 1965-1968 by Air Force 

- Decrease in DDT&E cost 

- Increase in OPS cost 



MSC studied 53 Orbiter 
configurations during 1971-1973 




Rebalance for New Budget Constraints 





Figure 86. Space Shuttle history — example Phase B' configurations. 
Table 28. Space Shuttle history — Phase B". 


November 1971 

December 1971 

March 1972 

May-October 1973 

Phase B' costs still too high 

• $2.8M contracts to continue 
“Grumman/Boeing 

- Lockheed 

- MAC-DAC/MM 
-NAR 

• New Ground Rule: 

Stage below 4,100 mph 

• Technical issues 

- Booster configuration 

• Fully recoverable, new liquid 
engine, pressure fed 

• Fully recoverable, based on 
SIC stage 

• Solid boosters 
-Series burn/parallel burn 

• Separation dynamics 
(favored series) 

• Ground handling 
(favored parallel) 

• Main engine start on pad 
(parallel) 

• Cost analysis (favored parallel) 

Adopted parallel burn 
Added abort SRM’s 

Adopted solids j 

- Cheaper development 

- Faster 

- But higher OPS cost 

- More unknowns 

MM and others TPS study 

- Ablative versus reusable 

- Tile technology 


Design Significantly Impacted by Budget 






McDonnell douglas/martin marietta north american/rockwell 



Figure 87. Space Shuttle history — example Phase B" configurations 











6.1.6 STS Phase C 


Phase C, detail design, began with a baseline configuration established at the end of Phase B . 
Table 29 shows the main contractors and major configuration changes. In 1972 and 1973, contracts were 
signed for the development of the Shuttle elements and for systems integration. During the 2-year detail 
design phase, the Shuttle configuration underwent a number of design modifications in order to achieve a 
workable system and attain the desired balance of system performance. There were six major overall 
configurations involving geometrical and structural changes, adding and deleting air-breathing engines 
and abort SRM’s, and subsystem evolution (see fig. 88). The balancing act between subsystems/design 
functions and requirements/attributes continued until the final production vehicle configuration was 
released. Even after the point where the design was frozen, tradeoffs and balancing were done between 
requirements, performance, and operational constraints. 

The following observations are among the many which can be made concerning the development 

history: 


• Political decisions heavily influenced the development process. Budgetary constraints drove 
the design itself. This is common for programs of this magnitude. 

• Requirements underwent major changes during the process, significantly driven by the above 
considerations. 

- The concept started as fully reusable, but cost drove to the stage-and-a-half configuration 
of Phase C. 

- DOD requirements also drove the configuration. 

- The continuous requirements flux demanded a continuous design balancing act 

• The development effort was extensive, spanned several years, involved most of the space 
community, and had large expenditures. 

- Hundreds of variations of vehicles were studied. 

- Seventeen contractors participated in 29 major study contracts worth $127M issued from 
1969 to 1973. 

- There also was significant funding for technology groups and large in-house activities by 
NASA and the Air Force. 

• The complexity of the configuration and its resulting sensitivity and interactivity provided design 
challenges which carried over into operational complexities and flight constraints. 
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Table 29. Space Shuttle history — Phase C. 


Contract awards 

Major Configuration Changes 

August 1971 

Orbiter structural weight trades 

“Vehicle 2A” (150K orbiter) 

• SSME to Rocketdyne 

(-1,000 lbs) 

• Orbiter resized smaller 

(Contract signed 


• Wing planform change 

August 1972 after protest) 

• Thrust structure, wing spar, drag 

• Body reshape 

attachments, separate crew module, 

• Air-breathing engines returned (ferry) 

July 1972 

composite bay doors, composite 

• Abort SRM provisions returned 

• Orbiterto Rockwell, system 

OMS pods 

• SRB’s further shortened and moved aft 

integration to Rockwell 

See 1994 AIAA Propulsion Conference 

• ET shortened 

August 1973 

Short Course on How Phase 

“Vehicles 3 and 4" (mid-1973) 

• External tank (ET) to Martin 

B7C Requirements Impacted SSME 

• Minor geometry adjustments for 

• Solid rocket boosters 

Design 16 

aerodynamics and aerothermo 

(SRB’s) to USBI 


• ET shortened 

•SRM’s to Thiokol 

Scenario of vehicle modifications 

• ET retrorocket (spike) removed 

Requirements 

(see fig. 88) 

• SRM thrust termination dropped 

• 65,000 lbs due east 

“Vehicle 1” (authority to proceed (ATP)) 

“Vehicle 5” (early 1974) 

• 15' x 60' payload 

"Vehicle 2” (program readiness review 

• Modified OMS pods 

• 1,265 mi cross range 

(PRR)) 

• Abort SRM provisions dropped 


• Moved OMS Pods 

• Forebody shape 

• Added orbiter braking chute 


• Orbiter/ET incidence 

“Vehicle 6” (production, mid-1974) 


• Abort SRM’s deleted 

• Exposed RCS 


• Air-breathing engines deleted 

• ET and SRB lengths changed slightly 


• ET Ogive nose 

• Umbilical door modifications 


• SRB’s shortened, moved aft 

• SRB TVC added 

• Thermal glass on windows 


Balancing Act Continues: Requirements/Design and System I 
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6.2 Design Process for Flight Mechanics With Loads Modeling Example 

In this section, the complex technical integration process for flight mechanics and loads modeling 
is illustrated by describing how this process has been accomplished for past programs. 

6.2.1 Space Shuttle Flight Mechanics Technical Integration 

The Space Shuttle is used as the primary example for technical integration of flight mechanics. 
Table 30 shows a set of initial assumptions developed during the preliminary design phase in order to 
simplify the design process. These assumptions cover topics such as assuming that the ascent loads are 
bounded by reentry loads. Some of these assumptions proved to be wrong, such as the assumption that 
ascent crosswinds would not impact design. In order to achieve proper integration, discipline panels were 
formed initially to handle such topics as aerodynamics, loads, etc. 

Table 30. Space Shuttle preliminary design. 


Preliminary Design 

Allocations and assumptions implemented to simplify the design process: 

• Ascent loads required to be within re-entry thermal and aero loads 

• SRB not designed by water impact but assessed by attrition 

• Weight allocation: 

- Element dry weight and geometry 

- Vehicle “glow” 

• SRB/TVC 

- Full TVC 

- Trim TVC with active ailerons 

• Ascent crosswinds would not impact design 

- Consequences: 1 . High wing loads; wing failed 

2. Element interface loads sensitive to 
combined aero loads ascent accelerations 

Panels formed to enable technical penetrations and communications: 

• Panels: Aero, Flight Mechanics, Loads, etc. 


Going into the detail design phase, problems in integration started to occur, and two major working 
groups were formed to aid the integration process (table 31). The Ascent Flight System Integration Work- 
ing Group (AFSIG) and Propulsion System Integration Working Group (PSIG) were formed as integrating 
and sounding groups for the panels, with recommending authority to the System Integration Manager and 
Shuttle Program Manager. The first major tasks were to set up procedures and methodologies as well as 
defining appropriate parameter uncertainties to use in design. These uncertainties were identified by the 
various disciplines for each flight event (fig. 89). AFSIG’s role was to assure completeness and consis- 
tency of the parameter uncertainty matrix, assuring that the uncertainty levels chosen were sufficient for 
design but not overly conservative. Figure 90 is an excerpt from the parameter uncertainty matrix. More 
detail of the parameter uncertainty matrix is given in the appendix. 
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Table 31. Space Shuttle detail design. 


Detail Design 

• Formed working groups 

- AFSIG and PSIG 

- Expanded number of panels; integrated by AFSIG and PSIG 

• First major task 

- Set up procedures and methodologies 

- Set up parameter uncertainty matrix by flight events 

• Outputs of technical integration activities 

- Impacts on vehicle design and sequence 

• Parameter combinations for engine out; detuned wind gust and 
engine-out by 6 seconds and all other uncertainties were la. 

• Baselined lift-off dynamic analysis using 2c worst-on-worst approach. 

• “A” factor and squatcheloid approach baselined for max Q. 

• 95% wind speed and 1/2 magnitude of shear and gust applied 
deterministically; other half of the shear and gust used as uncertainty 
with other parameters for max Q. 

• Monthly mean wind biasing for design reference trajectory. 

- Impacts on procedures and models 

• Delayed SRB ignition 

• SRB separation motor orientation, location, fuel combination, timing, and 
number of motors. 

• Necessary load relief control increased thermal environments, increased 
TPS, and reduced payload. 

• Three axis load relief baselined for max Q. 


ORGANIZATION 

SYSTEMS DYNAMICS 
LABORATORY 


MARSHALL SPACE FLIGHT CENTER 


AFSIG REVIEW 


R. RYAN 


APRIL 1986 


Parameter Matrix 


Discipline 

Trajectory Performance 

Pogo 

Flutter 

Control 

Thermal 

Liftoff Clearance (Drift) 

Separation 

Loads 

Environments 
Overpressure 
Acoustic 
Shock 
Winds 
Propulsion 
Dynamics 
Criteria 
Failure Modes 


Event 


Prelaunch 
Launch 
Max Q 
Max G 

Pre-SRB Separation 
Post-SRB Separation 
SRB Separation 
Second Stage Ascent 
ET Pre-Separation 
ET Separation 
Total Ascent 


Figure 89. Space Shuttle AFSIG — example parameter matrix event. 
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ED61 


ORGANIZATION 

SYSTEMS DYNAMICS 
LABORATORY 


16 


MARSHALL SPACE FLIGHT CENTER 


BASIC PARAMETERS 


R. RYAN 


APRIL 1986 


SRM Propulsion 

• TC227A-75 Thrust Versus Time Curve Per SE-01 9-083-2H 
(SRB System Data Book) for Bulk Grain Temperatures 
(TC227H Is Proposed as Update) 

• Flight-to-Flight Propellant Burning Rate 


•Thrust Level Development Uncertainty 

•Thrust Oscillation (Dynamic Factor Assumed for 
Loads Analysis) 

• Steady-State Thrust Mismatch Between Motors 


•Thrust Misalignment 
• Flight-to-Flight Thrust Level Dispersion 


Analysis Tolerance 

ETR - 81 T (Mean)/ 83.4 T (Max) 
WTR - 52 T (Mean)/ 44.5 fl F (Max) 


{ 


± 5.3% (One SRM) 
±4.7% (Two SRM's) 

±3% 

±5% 


85,000 lb (Ref. vol. X, 
fig. 3.3.2.2e) 

± 0.75° Per SRB 

± 5% Single Motor 
± 4.9% Both Motors 


Aerodynamics 

• Pressure Distribution Test Data Match with Aerodynamic ± 3% 

Coefficient Test Data 


• Elevon Deflection Schedule #6 (Hinge Moment Limiting 
Feedback) Per Rockwell Internal Letters AC DA/FS A/76-527 
and 531 


A5 e o = f (ACj-im = 0.02) Aero 
Data Adjusted to New 
(5 e o + A8 e o) 


• SD72-S H-0060-2 (Mated Vehicle Aero Design Data Book) 


None 


• Include Aerodynamic Tolerance Effects on Coefficients: Wind 
Tunnel Deviations Plus Power-on Deviations Plus Reynolds 
Number Effects 


Values Per PRCB Briefing on 
8/18/76 MCR 3378 “5.3 Ascent Load 
Adjustments” 


Figure 90. Space Shuttle AFSIG — example parameter variations. 
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Many impacts to the design occurred due to how the parameters/uncertainties were implemented. 
Impacts that were too severe were resolved by changing how the uncertainties and their application were 
used in the design process. The prior approach of worst on worst was too severe for the high performance 
characteristics of a vehicle like Space Shuttle. Table 31 lists a number of these procedural and criteria 
changes made by AFSIG to minimize the effect of uncertainties and maintain a highly reliable system. 
Vehicle operational changes were made to reduce impacts of uncertainties on loads, etc. For example, the 
SRM ignition was delayed 5 sec after SSME ignition in order to capture a minimum stored energy condi- 
tion, thus reducing lift-off dynamic loads. Three-axis load relief was another addition. These changes 
reduced loads but resulted in a loss of performance. 

Table 32 delineates other changes that were made to reduce weight/increase performance 
(i.e., reducing the safety factor on the external tank from 1 .4 to 1 .25, increasing the SSME thrust level from 
100 to 109 percent, introducing the high performance SRM, etc.). Special teams were formed to solve 
particular design problems such as the Orbiter Tile Team, SSME Design Team, and SRB Recovery Team. 
Certain risk mitigation activities were performed such as the mated vehicle ground-vibration test and 
SSME improvements. 


Table 32. Space Shuttle change examples. 


Detail Design 


• Other tasks 
-ET1.25F.S. 

- All welded SSME 

- HPM/SRM 

- Orbiter improvements 
-109% SSME 

• Special teams 

- Orbiter tile team 

- SSME team 

- SRB recovery team 

• Risk mitigation activities 

- Mated vertical ground vibration tests 

- Engine improvements 



Planned performance evolution 
enhancements after first flight 


Even with all these special activities, problems occurred such as loss of load margins on the orbiter 
wing and on the interface members between the orbiter and external tank and between the external tank 
and the SRB’s. The program was now in the flight test phase, so operational work-arounds were sought 
(see table 33). In order to launch safely with these lower margins, the Launch System Evaluation Advisory 
Team (LSEAT) was formed to perform day-of-launch wind monitoring with specific constraints. As the 
system evolved, day-of-launch I-load updates were employed which utilize the measured wind profile 
2 hr prior to launch. Many design changes were implemented to reduce problems uncovered early in the 
flight test program such as water troughs for overpressure reduction, super light weight tank (SLWT) for 
added performance, etc. 
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Table 33. Space Shuttle change examples — test and operations. 


Flight Test and Operations 

• Changes required* 



- Organized LSEAT 

- Day of launch monitoring/launch constraints 

— Balloon flight day of launch/realtime flight assessment 

- Day of launch l-loads update 

- Special instrumentation for SRB AFT skirt 


Two Duct HGM 

- ET TPS (Ice team) 

=> 

Damping seals 

- Engine operations procedures; engine redesigns 1 

Single crystal turbine blades 

- Redesigned AFT skirt due to water impact 

Large throat nozzle 

- Two changes in SRB parachutes 


Silicon nitride bearings 

- Changed how orbiter tiles were attached 

- Debris/tile team 
-SSME 104% versus 109% 

- SRM overpressure accommodations 

- Changes to meet EPA regulations 
— ETTPS 

- RSRM 

- SLWT 


P and W high pressure turbo pumps 

* This list is representative; not all inclusive. 




6.2.2 Loads Modeling Example 


The basic process, figure 91, models the plant (the vehicle) with its uncertainties as well as the 
natural environments with their uncertainties. Combining these together produces a response with 
variations. What is needed is for the response to have an assured probabilistic level to produce adequate 
margins. Achieving this requires considerable work with the input variables, the uncertainty combination 
approach, and the design. The process starts with the generation of the trajectory, figure 92, which 
produces the basic ideal performance. Since the ideal cannot be reached because of the effects of 
variations, in order to secure analysis efficiency, specialized reference trajectories are generated. These 
reference trajectories become the basis for analyses using uncertainties to determine perturbated responses. 
These responses are used as inputs to generate loads acting on the vehicle (see fig. 93). The figure shows 
the outputs of the responses that become the inputs for loads. The sketch shows this wind-induced 
perturbation from the nominal trajectory as well as the dynamic elastic -body response. 


Parameter 
Matrix and 
Uncertainties 





Response 

Variations 



Figure 91. Overall concept for flight mechanics. 
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Step 1 


Ideal Optimized 
Trajectory 
(Response) 


Step 2 


Reference 

Trajectory/ 

Trajectories 


Step 3 


Non Ideal 
Perturbed 
Response 
(Uncertainties) 




- Ideal Optimized Trajectory and 
Potential Payload Margins 

- Input to Step 2 


- Specialized Trajectories Generated to 
Achieve Analysis Efficiency 

- Reference Trajectory input to Step 3 


- 3 o Response 


Note: Steps 2 and 3 Performed for and Tailored to Each Mission Phase 
as Well as for Special Situations 


Figure 92. Method to achieve performance goal. 


» Rotational Acceleration 

* Translational Acceleration 

• Gimbal Angle and Rates 
► CG offset 

• Thrust 

* Aero Loads, 

Moments, and 
Distribution 



\ 


Reference 
Trajectory To 
Orbit 



Target 

• Location 

• Payload 
and 
Margin 


Natural Environment 
-Wind Velocity and Direction 
-Temperature 
- Density 


Data Requirer^ 


Figure 93. Illustration of design process: structural loads. 
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To achieve the most conservative design, ideally one would want to design for the comers of 
parameter uncertainties space, as shown in figure 94; however, this is generally not practical because of 
performance impacts. The next most desired approach is to accomplish a pure statistical analysis such as 
Monte Carlo of the vehicle parameters and the natural environments. This has not been practical until 
recent years and is still costly. Therefore, the synthetic wind model was developed along with a 
root-sum-square (RSS) and A-Factor approach for uncertainties (see table 34). The approach is a 
conditional probability approach which says that given the 95 percent wind speed combined with 
99 percent shear and gust effects RSS'd, the load must be maintained within the 3-sigma bound. This 
approach was very efficient for Saturn Apollo and has been validated by a Monte Carlo analysis. 



— Ideally the desire is to design for the corners of the box such that the input parameters and the 
plant are good tor the extremes. This results in overly conservative loads. 



Figure 94. Structural loads illustration. 


The Space Shuttle followed a similar approach during design with some significant changes in the 
wind model (see table 34). Other than the wind model change, the same conditional probabilistic approach 
was used. The wind model change was introduced to remove conservatism without impacting safety. 
Figure 95 shows how the approach was applied to different load parameters called squatcheloids that are 
q-alpha and q-beta plots as a function of Mach number. Combining the squatcheloids as a time function of 
Mach number produces a loads envelope tube as a function of ascent trajectory tune. At each point on the 
squatcheloid, time consistent accelerations, velocities, and positions are used for load analysis. This 
approach saved significant amounts of computer time. The X-33 patterned their approach after Shuttle but 
used only 2-sigma variations instead of 3-sigma (table 35). 
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Table 34. Structural loads illustration. 


• The desire is an all up Monte Carlo of the vehicle parameters and the natural environment parameters. 

In the past and to some extent in the present, this was not possible or, if possible, not design analysis 
efficient. As a result alternate procedures were developed. 

• Saturn Apoiio/Skyiab 

Saturn used a conditional probabilistic approach, where a synthetic deterministic wind profile is the 
condition. The vehicle's response is determined to this profile using the mean and the 3a parameter 
uncertainties (individually) producing a set of responses which can be root sum squared then multiplied 
by a factor of three producing: 3a response against the condition (winds). 

-Wind model (deterministic) (the synthetic wind profile model was generated for each critical 
altitude/match number) 

• 95% worst month scalar wind speed 

• 99% worst month wind shear and gust (due to the conservatism, the shear and gust 
were RSS‘d) 

- Plant models (Two) 

• Rigid body with and without propellant sloshing dynamics 

• Rigid plus elastic body with propellant sloshing dynamics 

- Parameter uncertainties 

•3a about mean 

• Normal distribution assumed 

-Analysis approach 

• Run response to synthetic wind profile (one altitude) using mean of parameters 

• Run response to synthetic wind profile (same altitude) using mean of all parameters but one, 
which is the +1a level 

• Repeat for -la level of parameter 

• Repeat process for + and - of each individual parameter 

• RSS for each response, develop a single time response run which produces a time consistent 
response that produces the same 3a peak. (Time consistent set of response data required 
for balanced load set.) 

• Repeat process for each critical altitude/Mach Number 

• Produce conditional probability set of design data 

• Engine out phased with wind gust 

-Operations 

• Bias trajectory to monthly mean wind to obtain margins. 

- Validation of synthetic wind approach was made using individual measured wind profiles (50m 
wave length, 150 profiles per month) in conjunction with Monte Carlo approach. (Winds only, 
vehicle parameters nominal.) Good correlation with synthetic profile. 

• Space Shuttle 

- Space Shuttle used the conditional probabilistic approach; however, the wind profile model was 
changed. (Remove conservatism) 

-Winds model (synthetic profile; looked at using directional speed change). 

• Trajectory biased to monthly mean wind (design) 

• Synthetic profile directional 

- 95% worst month wind speed 

- 50% of 99% shear and gust magnitude RSS'd. 

• 50% of 99% shear and gust treated as uncertainties along with all other vehicle parameters. 

- Winds model (Individual profiles) 

• Monthly detailed wind profile (50m wave length) 150 per month (special studies) 

-Analysis approach 

• Same conditional probability approach as was used for Saturn except using squatcheloid 
as output. (See fig. 95) 

• Simultaneous pitch and yaw synthetic wind profiles required 

• Engine out delayed 6 seconds past gust peak, la vehicle parameter uncertainties, used with 
engine out 

• Bending dynamics response accounted for by multiplying rigid body loads by 10% (conservative 
based on special studies). Liftoff and landing analysis made using bending dynamic models. 

• Liftoff used 2a worst-on-worst parameter uncertainty method 





Nominal vehicle parameters, synthetic 

profile 95% speed, 50% shear, and gust 
RSS‘d, one specific Mach Number,* 
mean wind, and reference trajectory. 

3a vehicle parameters, 50% shear and 

gust synthetic wind profile, mean wind, 
and reference trajectory 

X A-Factor approach used to generate time 
consistent accelerations, gimbal angle, and 
angle-of-attack data for loads. 


* Process repeated for each Mach number 


Figure 95. Structural loads illustration — squatcheloid approach for loads. 


Table 35. Structural loads illustration — X-33. 


- X-33 used the conditional probability approach for max "Q"; same as Shuttle for lift off 

- Monthly mean wind biasing 

- 2o parameter variations 
-Wind model 

• Synthetic profile 

- Analysis approach 

• Squatcheloid approach as was used for shuttle 
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Table 36 is a summary of lessons learned this example. Although only a snapshot of the loads 
process was provided, the lessons are applicable to all the various design activities. Uncertainty analysis is 
required, and this analysis complicates the design process. Creativity and innovation of engineers are keys 
to establishing accurate, efficient approaches for the specific vehicle being designed. 


Table 36. Structural loads illustration — summary. 


Design Process for Flight Mechanics wilh Loads Modeling Example 


• Uncertainty analysis key to a reliable design 

• Uncertainty significantly complicates the design process; load analysis used as example; 
established and verified 

• Similar uncertainty analyses were also used for all other design functions 

• Creativity and innovation of engineers key to establishing accurate, efficient design process. 


Uncertainty Drives Innovative Methodology 
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7. EXPERIENCE-BASED KNOWLEDGE 


7.1 Survey of Experienced Practitioners in Aerospace 

A survey was conducted of experienced practitioners in aerospace using the question, “What is the 
essence of engineering design based on your many years of experience?” Many have responded with very 
clear and succinct lessons. Their responses have been collected and are included by their individual names. 
The statements are unaltered and provided without comment. 

7.1.1 Janies Blair (Retired NASA, presently at University of Alabama in Huntsville) 

“In a vehicle system, all parts are connected; a change in one affects the others. The more fully the 
design organization acknowledges this system connectivity, by means of communications, 
organization, and especially the individual engineers’ perspective, the more successful will be the 
design.” 

7.1.2 Bob Brotherton (Former McDonnell Douglas, presently with Boeing) 

“Engineering is logical.” 

7.1.3 Jack Bunting (Lockheed Martin, Denver) 

“Test what you fly, and fly what you test.” 

7.1.4 W. E. Campbell (Retired Aerojet) 

“Success lies in attention to detail, with a methodical top-down approach to identify the areas of 
concentration.” 

“One-fourth to one-half of historical rocket engine failures seen to be attributable to out-of-print 
hardware, process escapes, and the like. One probable contributor is insufficient priority on 
producibility in favor of performance, weight, and envelope. It must be the mandate of project and 
technical management to balance these priorities.” 

“Stacking worst-on-worst tolerance (or schedules, costs, contingencies, margins, etc.) results is an 
untenable, noncompetitive design, product, or program. Some form of probabilistic approach will 
point toward a competitive but successful solution.” 

“Project scheduling should include small enough task increments that an event “miss” can be 
recovered with reasonable downstream workarounds. Last minute surprises on long-span tasks are 
project disasters.” 
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“Nearly everything in the world has a distribution. A simplified probabilistic approach (which does 
not become frustrated by imprecise algorithms or incomplete data bases) is an excellent tool to 
identify drivers, screen options, and evaluate sensitivities.” 

“A part fracture failure occurs when “stress” (in some form) exceeds “strength” (in some form). 
This can be the starting assumption for failure analysis, which must identify and rectify the 
combination of higher (than expected) stress elements and/or lower (than expected) strength 
elements — both of these including the effects of operating conditions and environment, 
manufacturing processes, part history, and the like — that resulted in failure.” 

7.1.5 Chris Chamis (NASA Lewis Research Center) 

“Simplicity in formulations wins over complexity in every respect — succinctly better-faster-cheaper.” 

“Simple solutions to engineering problems require insight that is gained by experience and maturity.” 

“Major hurdle in simplicity is resistance from inexperienced colleagues and not very knowledgeable 
supervisors.” 

“Simple solutions to complex problems require continuing management support: person power and 
other required resources.” 

“Successful engineering solutions are not based on the proverbs: ‘The nail that sticks out gets the 
pounding’ or ‘The wheel that squeaks gets the grease,’ which is the current practice.” 

7.1.6 David Christensen (Lockheed Martin, Huntsville) 

“One good test is worth a thousand opinions.” 

“Too much analysis can cause Design Paralysis.” 

7.1.7 Peter Christie (Boeing Seattle) 

“It is important to always do an analysis before testing. It is equally important to conduct at least 
one valid test in order to confirm the accuracy of the assumptions in the analysis.” 

“Engineering design knowledge must be combined with an understanding of materials and 
manufacturing process in order to achieve the most successful design.” 

“The performance of each system in an aerospace design affects the performance of other systems 
in the design. For example, in pressurized commercial aircraft fuselage, all joints are sealed with a 
polysulphide sealing system. The sealant adds weight and cost and affects the fatigue life of structural 
joints. It also minimizes the bleed air requirements of the engine, while increasing the corrosion 
resistance of the joint.” 
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7.1.8 Werner Dahm (NASA MSFC Chief Aerodynamic Scientist) 

“Mother Nature does not read our paper. If we don’t follow her way, she lets us fall.” 

“Paper is patient. Sense or nonsense, it accepts all we write.” (This is an old German proverb.) 
“As your design proceeds, weights always go up.” 

“The chief decision maker should steer clear of the glory hounds. Their quest for personal fame and 
glory has cost us dearly and will always do so.” 

“If you aim for about 80 percent of the theoretically possible performance, your costs will stay 
moderate and your chance of success will be good. If you aim for more, your costs and risk will 
grow exponentially.” (This caveat was passed to me by Hans Multhopp, the designer of the FW 190 
fighter plane of late WWII.) 

7.1.9 Harold Dioron (Retired NASA, presently with InDyne, Inc.) 

“A complex model isn’t very useful without a simple model to guide interpretation and provide 
sanity checks.” 

7.1.10 Jim French (NASA and Aerospace Consultant) 

“In a system design, no change takes place in isolation. Every change has system level effects and 
any change no matter how good it sounds in isolation, must be reviewed in terms of its impact upon 
the system and every other subsystem.” 

7.1.11 Philip Glynn (Retired NASA, presently Boeing Space Station) 

“Engineering is the process of creating, evaluating, and assuring performance of any defined human 
need.” 

“Engineering uses the laws of physics and mathematics to expand man’s horizons and improve the 
quality of life on earth. As such it is the enabling environment to improve man’s relationship with 
man.” 

“Engineering excellence is a state of satisfaction known only to the group which has endured the 
pain of attention to the details.” 

7.1.12 Micheal Griffin (Orbital Sciences Corporation) 

“Look aggressively. The absence of a symptom does not imply the absence of a problem.” 

“Don’t shoot the messenger. Messages, but not problems, will cease arriving.” 
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7.1.13 Ron Harris (Retired NASA, presently with Boeing North American) 

“Arrive at a decision, don’t rush into them.” 

7.1.14 John L. Junkins (George J. Eppright Chair, Texas A&M) 

“Cooperate with Mother Nature to the maximum extent possible, minimum energy solutions are 
almost always the most reliable.” 

“It is hard to conduct an orchestra when every musician thinks himself a composer.” 

“Faster, Better, Cheaper? Maybe, but not very likely with five levels of management.” 

“Keep simplifying the most important questions and simultaneously try to define corresponding 
analytical, computational, and experimental tests that answer the question.” 

“World-class determination will usually trump world-class intelligence, but thank God for the 
miracles that can be performed when you find both attributes in the same person. 

“The best advice I can give to a project manager: Know who your best engineers are, seek them out 
immediately when the tough questions arise, and challenge several proven individuals (not a 
committee) to propose solution strategies. Then convene the committee.” 

7.1.15 Dick Kohrs (Retired NASA, Associate Administrator, presently with Kistler) 

“Systems Integration is 95 percent communication and 5 percent engineering.” 

“It is better to be on orbit and be criticized for not having enough capability, than to be on the 
ground and be criticized for not being in orbit.’ This is what J.R. Thompson preached to me during 
Space Station.” 

“Consistency is the work of dull minds, but we must be consistent.” 

7.1.16 Wayne Littles (Retired NASA , Associate Administrator, MSFC Director, presently 
with Pratt and Whitney) 

“Capable discipline engineering with the products accurately transmitted to well trained 
manufacturing technicians and software developers, along with a thorough test program, are necessary 
elements in producing quality flight hardware and software, but the essential ingredients to ensure 
program success are sound Systems Engineering and effective communications.” 

7.1.17 John McCarty (Retired NASA, presently a consultant) 

“Proper use of dispersions, tolerances, in analysis and test is key to propulsion system design.” 
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“A high quality propulsion system is one that has high reliability.” 

“Failures are when engineers learn how things really work.” 

“The price of any design change, because it is a change, is the introduction of new failure causes. 

7.1.18 Dale Myers (Retired NASA Deputy Administrator, presently with Kistler) 

“Keep it simple stupid” (The KISS Program). 

“If it isn’t worth doing at all, it isn’t worth doing well.” 

“A program without reserve is like a dinner without wine.” 

7.1.19 Owen Morris (Retired NASA) 

“When attacking a problem, remember that things usually are truly as they appear to be.” 

7.1.20 Joyce Neighbors (Retired NASA, presently with Lockheed Martin) 

Career path in engineering: “First become a specialist in some discipline, learn how other disciplines 
interact with yours. Learn systems engineering but stay grounded in your specialty; this gives 
experience and technical qualification for becoming an engineering or program manager for high 
technology products.” 

Mission success: “Understand and prioritize requirements for the life of the product early in design 
cycle. Analyze during design and test to corroborate analysis before putting product into operations.” 

7.1.21 Larry Pinson (Retired NASA) 

“All the easy problems have been solved.” 

“As engineering managers, we like to focus on formal management structure while people motivation 
usually is the real issue.” 

“If people are sold on a project outcome, formal organization is nearly irrelevant.” 

7.1.22 Robert S. Ryan (Retired NASA, presently a consultant) 

“The higher the performance requirements, the greater the sensitivity (nonlinear) to variations in 
environments, design, manufacturing, etc. Performance requirements drive the design.” 

“Political viability shapes a project as much as engineering.” 

“The Physic (Mother Nature) of the problem reigns supreme (The God of Design). Either you bow 
down to her or you fall down.” 
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“All design is a paradox, a balancing act. Understanding sensitivities, interactions, is the key to 
success.” 

7.1.23 Lucien A. Schmit, Jr. (Retired Professor, University of California) 

“The engineer’s main task is to anticipate possible failure modes and loading conditions. 
If we are not imaginative, nature will punch a hole right through our design.” 

“The value of simple limiting cases as test problems for assessing computer codes cannot be over 
estimated.” 

“Behavior sensitivity analysis and optimum design sensitivity analysis are powerful tools for 
obtaining quantitative answers to ‘what if’ questions traditionally asked by designers.” 

7.1.24 Luke Schutzenhofer (Retired NASA, presently at University of Alabama in Huntsville) 

“Skillful leaders communicate the goal and objectives, reward creativity and good work ethics, 
consider all ideas, encourage debate, and discourage the fear of failure.” 

“Focus on working the right problems right.” 

“Better can be the enemy of good.” 

7.1.25 David Sisk (Lockheed Martin, Huntsville) 

“In designing any structure, start with and continuously focus on the joints. If you get the joints 
right, the rest will fall into place.” 

7.1.26 Parker S. Stafford (Retired Martin Marietta, Consultant) 

“The design, development, and test of a system should be done with the mission operations objectives 
in mind; i.e., systems tests should duplicate real mission operations and sequences. Use flight 
hardware, software, and ground systems wherever possible.” 

“Flight software should be validated in a realistic mission dynamic simulation environment which 
is functionally equivalent to the actual environment. This should include the initial flight load and 
all planned and contingency uplinks to the spacecraft.” 

“Analysis data used to define qualification tests, operating ranges and tolerances, etc., should be 
configuration managed as released engineering.” 

7.1.27 John Thomas (Retired NASA and Lockheed Martin) 

“Any endeavor without understandable, achievable objectives and well thought out plan will not 
enjoy success.” 
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7.2 Design Suggestions From Selected References 

7.2.1 J.E. Gordon (Author of Structures, or Why Things Don’t Fall Down 5 and The New Science of 

Strong Materials * 5 ) 

“All structures will be broken or destroyed in the end. Just as all people will die in the end. It is the 
purpose of medicine and engineering to postpone these occurrences for a decent interval; the question 
is: What is to be regarded as a decent interval?” 

7.2.2 Helmut Horn (Deceased, NASA and V-2 German rocket engineer) 

Provided by Robert Ryan 

“If you can’t explain it with a simple analog, you don’t understand it.” 

“You cannot be a good system engineer unless you have penetrated one discipline in depth.” 

7.2.3 Henry Petroski (Professor of Civil Engineering, Duke University, and author of To Engineer 

is Human: The Role of Failure in Successful Design 16 and Design Paradigms: Case Histories of 
Error and Judgment in Engineering 17 > 

“Every solution of every design problem begins, no matter how tacitly, with a conception of how to 
obviate failure in all its potential manifestations.” 

“If any small change is made to a system, the whole system must adjust to that change. 

“Lessons are best learned when we are familiar with a wide variety of textbook case studies of past 
failures, not only within our own field but also outside it, so that when we do make analogous errors 
we get a nagging feeling that something similar might be wrong in our reasoning and that we 
should double check our work.” 

7.2.4 Stuart Pugh (Author of Total Design 3 ) 

“Concept selection improperly done can never be righted with the best engineering. Neither can the 
best concept selection be saved (realized) using poor engineering.” 

7.2.5 David Pye (Author of The Nature of Design 6 ) 

“When you put energy into a system you can never choose what kind of changes shall take place 
and what kind of results remain ... All you can do, and that only within limits, is to regulate the 
amounts of the various changes. This you do by design.” 
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7.3 Lessons Learned 


The combined experience of the authors in conjunction with this activity, the survey of experienced 
aerospace workers, and the referenced literature have resulted in a series of lessons learned for technical 
integration of launch vehicle design. Each lesson learned has a subset of attributes and/or tasks for 
accomplishing or applying the lesson. 

7.3.1 Specific Lessons Learned 

1. Although engineering skills are essential, people skills are mandatory for achieving successful 

products. 

- Choose a strong leader with decision-making capability who listens and encourages everybody 
to integrate. 

- Organization is a tool to accomplish the job; however, with proper leadership and motivation, 
the organization is secondary. 

- Provide a reward system to encourage the alignment of roles and responsibilities with project 
missions and objectives. 

- Encourage engineers to enhance their cooperative interactive skills as well as their technical 
skills. 

- Train engineers to be specialists with a systems focus. 

- Reward specialists who participate in integration activities in order to formulate a world view 
of the total system. 

- Provide an open environment which encourages innovation and stimulates communication. 


2. Manage to ensure good technical integration. 

- Technical integration is crucial to the design process. Make eveiy effort to encourage technical 
integration and assess that it is being done. 

- Communication is the key, predominant part of technical integration. 

- Most integration communication is informal, both within and between planes. 

- Understand the physics of interaction. 

- Continuously check requirements flow. 

- Continuously check assumptions. 

- Proper compartmentalization (subsystems/design functions/disciplines) facilitates integration. 
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- Working groups can enhance technical integration. 

- Focus people skills toward integration. 

- Integration is everyone’s responsibility, but leadership must ensure technical integration. 

3. Manage to ensure proper concept selection. 

- The right concept selection is critical. The best detailed design will not correct a flawed 
concept selection. 

- Put sufficient effort into front-end engineering (quality lever). 

- Ensure that options are fully explored, converging with successive refinement (greater detail) 
of concepts and requirements. 

- Pick a concept only after appropriate convergence of the various concepts; i.e., do not eureka 
the concept. 

- In early phases, discipline specialists must assess validity of sizing program results. Do not 
depend on sizing program alone. 

- Avoid concepts having too many low-level TRL’s. 

4. Requirements, constraints, and criteria greatly influence design. 

- Extemal/political considerations and constraints strongly drive design (for example. Space 
Shuttle). 

- Technical constraints also drive the design, so apply them carefully and judiciously. 

- Analyze and challenge requirements, constraints, and criteria at all levels to obtain the greatest 
possible engineering design flexibility. 

- Do not accept unrealistic schedules and budgets. 

- Poorly defined and vacillating top-level requirements cost the program dearly in terms of 
wasted design effort and compromised design. 

- Overspecified criteria suppress the creativity of the design engineer. 

- Criteria must be tailored for the specific project. 

5. All design is a balancing act between conflicting requirements. You get some of what you want 

with some of what you do not want. 
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- Balancing must occur among disciplines (energy redistribution). 

- Balancing must occur among program requirements, the design, and operating plans. 

- Cost, risk, and performance are linked attributes. An improvement in one attribute typically 
produces a detriment in another. 

- The balancing act requires open communication and key decision judgments. 

- Assessing risks versus consequences is a key ingredient of the judgment process. 

- Problems which cannot be cured in design must be compensated for in operational compromises 
and constraints (e.g., may lead to reduced probability of launch). 

- All designs must achieve margins or probabilities acceptable for safety while maintaining 
performance. 


6. Consideration of system sensitivities and uncertainties is crucial to design process. 

- Successful design requires that sensitivities and uncertainties be properly accounted for and 
managed. 

- Uncertainty significantly complicates the design process. Incorporate appropriate philosophy 
and procedures for handling uncertainty throughout the process. 

- System sensitivities (both within and between design functions) are indicators of how much 
concern should be given to uncertainties. 

- High performance systems have high sensitivities, requiring more attention to details of design. 

- Design must either reduce sensitivities and uncertainty or provide additional margin. 

- In the early stages of design, ensure that adequate margins are provided to cover the sensitivities 
and uncertainties of the specific vehicle, considering its coarse state of definition. 


7. Engineers’ judgment and creativity is essential to design process. 

- The complexity of the system requires applying judgment and innovation to the specific 
launch vehicle situation. This cannot be supplanted by dogma, rules, or recipe. 

- Tools enhance efficiency but cannot replace the judgment and creativity of the human mind. 

- Guidelines and criteria should be tailored or adapted to the particular project to avoid a dogmatic 
approach which unnecessarily constrains design solutions. 

- Many decision gates are not deterministic but are judgment based, requiring indepth discipline, 
system knowledge, and wisdom. 
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- The level of penetration is an engineering judgment, determined by project characteristics, 
design stage, sensitivity, and uncertainty. 

8. The design process is complex and laborious; improve it wherever possible. 

- Continually explore approaches to high-leverage improvements, both evolutionary and 
revolutionary. 

- Reduce process fragmentation; move toward more seamless design. 

- Improve design modeling, especially for cost, operations, and reliability. 

- Explore more direct synthesis approaches to better convert requirements to concepts and 
designs. 

- Improve the conceptual design process through better synthesis and higher fidelity repre- 
sentations. 

- Develop and mature an information system for efficiently conveying and displaying neces- 
sary design information to all participants. 

7.3.2 Associated Discussion 

Lesson 1: The first lesson is very important. It emphasizes people skills, putting them in the same 
category as the engineering skills. Dick Kohrs has said that “Communications is 90 percent of integration.” 
Whether it is 90 or 60 percent, it is key to quality products. The T-model presented earlier emphasizes this 
by requiring the discipline specialist to also have a system focus. The reward system of the organization 
must support this emphasis. 

Lesson 2: Just as important as the people skills is the truism, “You manage to ensure good technical 
integration.” As has been stated many times, “The integrity of the product is in the system; i.e., the integra- 
tion.” Engineering is accomplished by compartmentalizing the design tasks by subsystems and then 
further by design functions and disciplines. In order to ensure that each is compatible 
requires the process to be managed to achieve the goal of technical integration. There are many ways to 
achieve technical integration. Working groups (technical and systems) worked well on Saturn and Space 
Shuttle. Skunk works and design centers have also been successful. Management must ensure that each 
person understands and accepts his or her role and responsibility for technical integration. 

Lesson 3: Concept selection is key to successful products. It is generally accepted that at least 
80 percent of the life-cycle cost is determined during the concept selection stage. Pugh has said, 
“Engineering can never right a poor concept selection.” The quality lever indicates the same focus. The 
process is iterative, and it weeds out poor concepts, then looks in more depth at the remaining concepts. 
The process repeats with further increased depth until a clear winner is established. More than two new 
technologies are generally too risky for the development phase. The results of the trade studies and 
sensitivity analysis should be carried forward for future reference, along with the selected concept. The 
concept selection is therefore critical and must be emphasized by the leadership. 
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Lesson 4: Requirements, constraints, and criteria dictate the product design. Pugh says. “It is the 
mantle of the design.” As important as constraints, standards, and criteria are, if they are too restrictive, the 
design suffers; creativity and innovation are lost. Greenleaf in Servant Leadership^ emphasized this point. 
Many times they can dictate the design; instead of saying what is to be accomplished, they say how it is to 
be accomplished. Criteria sometimes are used to replace failure mode analysis, which is a mistake. Con- 
straints perform in the same way. The SSME weight constraint led to essentially an all-welded structure. 
The all-welded structure led to many fatigue and fracture problems in the welds, requiring many redesigns. 
Each project should carefully tailor criteria, constraints, and requirements, gleaning out all the “how’s” and 
reducing the “what’s” to only those that are essential. 

Lesson 5; All design is a balancing act between conflicting requirements. You get some of what 
you want with some of what you do not want. Pye has said, “When you put energy into a system and 
transform it, you cannot totally determine how that transformation will take place. You get some of what 
you want and minimize what you don’t want. This you do by design engineering.” This process is therefore 
a balancing act requiring firm technical and programmatic data. The decision in the end is usually a 
judgment call. The balancing act is first of all among the design functions and technical disciplines (energy 
redistribution), then between the program requirements, the design, and operations. Problems occurring in 
the balancing act, if not resolved, are pushed downstream and are solved through operational procedures 
and flight constraints, many times at high cost and reduced performance. 

Lesson 6: Consideration of system sensitivities and uncertainties is crucial to the design process. 
All major programs must find a way of designing for off-nominal conditions at a given probabilistic level 
of risk without over penalizing the performance and cost. Sensitivities of the system to the parameter 
variations are a measure of the level of concern one should put on an issue or an interaction. In general the 
higher the performance requirements, the higher the sensitivity of the response to any variation of the 
environments, manufacturing tolerances, etc. The sensitivity/performance curve is highly nonlinear. For 
example, in the case of fatigue of metals, the sensitivity curve is the inverse of the SN curve. Design for 
robustness is a desired method for dealing with uncertainties and sensitivities. A robust design is one where 
the responses to perturbations are adequately managed. Robust design falls into two categories. In the first 
category, a robust design could be one whose response is inherently insensitive to perturbations. In the 
second, a robust design could be one where the response is sensitive to perturbations; however, the system 
is designed such that the responses are maintained within acceptable limits. This can be achieved by 
designing within predetermined margins, controlling the variations in significant response parameters, 
actively or passively controlling the response, adding redundancy, and/or developing operational procedures 
and constraints. Therefore, several approaches, either individually or together, are listed below that can be 
used to accomplish robustness. 

• Increase margins 

• Reduce parameters uncertainties 

• Reduce sensitivities (response to uncertainties) 

• Redundancy 

• Operational procedures and constraints. 

All good design practices intelligently account for and deal with uncertainties and sensitivities as 
design parameters using appropriate philosophies, procedures, and tools. 


207 


Lesson 7: In the final analysis it is the engineer’s judgment, innovation, and creativity that develop 
the design and the product. All else are tools and aids to the human mind and the human skills. This means 
that the organization must be a learning organization that constantly hones personal mastery and team 
learning, using to the fullest the uniqueness/diversity of the individuals and the organization. In the end it 
is usually the engineer’s judgment, not deterministic metrics, that determines the product. Openness, 
acceptance, inquiry, and advocacy are essential to the engineer’s development and the quality of the product. 

Lesson 8: Finally, the design process is complex and laborious. Significant improvements are 
needed. Improve the process wherever possible. Apply lessons learned, and seek innovative ways to 
revolutionize the process, as discussed in section 5. High leverage areas to explore include those listed in 
section 7.3. 1 , item 8. Ideas for improvement can come from related fields of research such as multidisciplinary 
design optimization, or may come from apparently unrelated fields. The keys to attaining highly effective 
and efficient designs lie in the creativity, initiative, and judgment of the engineers who execute the design 
process and continually seek to improve it. 
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8. CONCLUDING SUMMARY 


This report provides a baseline characterization for the design process for launch systems as it is 
currently practiced. The various areas of emphasis are shown below. The current design process was char- 
acterized by using hardware/software compartmentalization and interconnected design function planes 
along with their corresponding decision gates for determining task completeness. The process character- 
ization provides a framework for a comprehensive integrated information and communication system that 
is recommended for any major effort. In specific areas suggestions for improvements have been made. A 
survey of experienced practitioners in aerospace on the essence of engineering was included, as was a 
detailed bibliography. Categorized lessons learned were provided, as were recommendations for future 
enhancements of the design process. 

The launch vehicle design process has been characterized, delineating the following elements: 

• Compartmentalization/reintegration associated with subsystems, design functions, and 
disciplines 

• Technical integration illustrating both the formal and informal aspects associated with design 
and discipline functions 

• Design function (plane) features and related significant decision gates 

• Information flow model associated with subsystems and design functions; i.e., the Ixl and 
NxN matrices 

• Major activities, interactions, and tasks. 

In addition to the characterization, necessary ancillary features of the design process were 
provided. They include: 

• Thumbnail sketch of process 

• Essentials considerations 

• Project technical framework 

• T-model of technical integration 

• Requirements, architecture, philosophy, etc., definition 

• Design sequence including conceptual, preliminary, and detail design stages 

• Illustration of the design process, shown through historical examples. 

Finally, the process characterization provided the following: (1) A means for practicing engineers 
to understand where they fit in the process, and their interactions, (2) a basis for understanding and improv- 
ing the process, and (3) the necessary symbolism to develop a variety of electronic design tools. The 
characterization applies to the design of any launch vehicle regardless of the organization/project structure. 
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9. RECOMMENDATIONS 


It is recommended that the launch vehicle design process characterization developed herein be 
utilized as a basis for understanding and improving the process. The current process must be constantly 
improved to increase effectiveness and efficiency. Lessons learned should be implemented and process 
improvement technologies should be incorporated as they are developed. The need to improve cost, 
reliability, and operability leads to the need for revolutionary advances in launch system technologies. 
These technologies include the categories of hardware/software technologies and process technologies. It 
is essential that hardware/software technologies be developed, and these activities are currently underway. 
Likewise, design process technologies must also be advanced to achieve effective and efficient designs. 

Specific recommendations for design process technologies are as follows: 

• Utilize the design process characterization as a basis for understanding and improving the 

process. 

• Refine the present process to improve effectiveness and efficiency 

- Work requirements and criteria to avoid stifling creativity and innovation 

- Design for simplicity 

- Improve design-to models 

- Integrate discipline analyses. 

• Pursue revolutionary technologies for major improvements in the design process such as 

- Advanced approaches for high-fidelity concept definition, sizing, and assessment 

- Unified compartmentalization/reintegration process into a seamless whole; i.e., seamless 
integration related to the subsystems, design functions and discipline functions 

- Improved process ideation toward advanced idea stimulus approaches; e.g., direct synthesis 
methods for concept identification 

— Advanced analyses technology; i.e., high-fidelity design-to methods for performance and for 
life-cycle attributes such as cost and reliability. 

The challenge of providing unlimited access to space requires the best of people, technology, and 
processes. Those who practice design must continuously improve the process. 
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APPENDIX A — NxN DIAGRAM FROM REFERENCE 2 


Figure 96 is the NxN information flow diagram from reference 2. It was developed by MSFC to 
represent typical information flow in the design process for example launch vehicles. This figure delin- 
eates inputs and outputs relative to various engineering design and discipline functions. For each entity on 
the diagonal, its information outputs are shown on the horizontal row, and its information inputs are shown 
on the vertical column. Therefore, connectivity is represented among all included entities. 
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Inputs 



Figure 96. NxN matrix from reference 2. 
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APPENDIX B— SPACE SHUTTLE PARAMETER MATRIX ITEMS 


Appendix B is an extract of certain portions of the Space Shuttle’s parameter matrix (figs. 97-99). 
Space Shuttle engineers developed matrices for each event and each basic design area. The matrix identifies 
the parameter, the parameter values or reference source, the 3-sigma parameter uncertainties, and, where 
applicable, the procedure for usage. The parameter matrix was developed by the specialists in each discipline 
area based on a combination of historical data, current analysis, and current testing. The parameter matrix 
document for a vehicle design must be a living document, changing both the base (mean) and uncertainty 
values (reducing if possible) as the design matures. Critical to the process is development of a comprehensive 
list of interacting parameters, both natural and induced. New systems need a comparable parameter matrix 
definition to assure uniformity in the design. The discipline specialists with their knowledge of the system 
and the data are central to its development. In the final analysis, design trades (balancing act) are made 
using uncertainties coupled with sensitivities and appropriate weighting metrics. The importance of parameter 
and uncertainty definition cannot be overemphasized. 
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Parameter Matrix 


Discipline 

Trajectory Performance 

Pogo 

Flutter 

Control 

Thermal 

Liftoff Clearance (Drift) 

Separation 

Loads 

Environments 
Overpressure 
Acoustic 
Shock 
Winds 
Propulsion 
Dynamics 
Criteria 
Failure Modes 


Event 


Prelaunch 
Launch 
Max Q 
Max G 

Pre-SRB Separation 
SRB Separation 
Post-SRB Separation 
Second Stage Ascent 
ET Pre-Separation 
ET Separation 
Total Ascent 


Figure 97. Parameter matrix. 
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16 


SRM Propulsion 

• TC227A-75 Thrust Versus Time Curve Per SE-01 9-083-2H 
(SRB System Data Book) for Bulk Grain Temperatures 
(TC227H Is Proposed as Update) 

• Flight-to-Flight Propellant Burning Rate 

•Thrust Level Development Uncertainty 

• Thrust Oscillation (Dynamic Factor Assumed for 
Loads Analysis) 

• Steady-State Thrust Mismatch Between Motors 


• Thrust Misalignment 

• Flight-to-Flight Thrust Level Dispersion 


Aerodynamics 

• Pressure Distribution Test Data Match with Aerodynamic 
Coefficient Test Data 

• Elevon Deflection Schedule #6 (Hinge Moment Limiting 
Feedback) Per Rockwell Internal Letters AC DA/FS A/76-527 
and 531 

• SD72-SH-0060-2 (Mated Vehicle Aero Design Data Book) 

• Include Aerodynamic Tolerance Effects on Coefficients: Wind 
Tunnel Deviations Plus Power-on Deviations Plus Reynolds 
Number Effects 


Figure 98. Basic parameters. 


NAME 

R. RYAN 

DATE 

APRIL 1986 


Analysis Tolerance 

ETR - 81 °F (Mean)/ 83.4 °F (Max) 
WTR - 52 T (Mean)/ 44.5 C F (Max) 


± 5.3% (One SRM) 

± 4.7% (Two SRM‘s) 

±3% 

±5% 


85,000 lb (Ref. vol. X, 
fig. 3.3.2.2e) 

±0.75° Per SRB 

± 5% Single Motor 
± 4.9% Both Motors 


±3% 


A5 e o = f (AC H m = °- 02 ) Aero 
Data Adjusted to New 
(5 e o + A8 e o) 

None 

Values Per PRCB Briefing on 
8/18/76 MCR 3378 “5.3 Ascent Load 
Adjustments” 
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Main Propulsion System 

• 3 SSME Thrust Level Throttling Range 

• Thrust Oscillation (Dynamic Factor Assumed 
Only for Load Analysis) 

• Equal Throttle Settings on All SSME's 

• With One SSME Out, The Two Remaining SSME's 
Operate at 1 09% Thrust 

•Thrust Misalignment 

• Mixture Ratio (6:1) 

• Variations in ET Propellant Load Left at 
Meco Result From Off-Normal SRM/SSME 
Performance and SSME Throttling History 

Mass Properties 

• Minimum Payload of 2,500 lb (Mission 3B) 

• Maximum Payload of 32,000 lb (Mission 3A) 

• Maximum Payload of 65,000 lb (Mission 1) 

Flight Control and Guidance 

• Rockwell Control #7 Per SD73-SH-0097-1 (Integrated 
Vehicle Flight Control System Data Book) 

• Elevon Schedule #6 (Hinge Moment Limiting Feedback) 

• Platform Misalignment 

• Accelerometer Misalignment 

• Accelerometer Null Offset (Time Variable) 

• Accelerometer MDM Bias 

• IMU Attitude Error 

• Actuator Hysteresis 

• Rate Gyro Misalignment 


Analysis Tolerance 

50% (MPL) to 100% (FPL) 
±5% 

None 

None 

± 3’ Per SSME 

None 

None 


None 

None 

None 


None 

± 0.02 Hinge Movement Coefficient 
± 0.5’ 

±0.5’ 

0.010 to 0.025g (Pitch) 

0.08 to 0.01 5g (Yaw) 

0.0248 
± 0.0083’ 

1.5 MA 
± 2 ° 


Figure 98. Basic parameters (continued). 
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LABORATORY 

BASIC PARAMETERS 


CHART NO.: 

18 

(Continued) 

DATE 


R. RYAN 


APRIL 1986 


Flight Control and Guidance (Continued) 

• Rate Gyro Hysteresis 

• Rate Gyro MDM Bias 

• Rate Gyro Zero Offset 

• SRB and SSME Forward Loop Gain 

External Environment 

• 95% Seasonal Winds Based on Monthly Wind 
Ellipse Data for WTR and ETR (TMX-7331 9) 

• Basic qa/qP: 95th Percentile Wind Envelope 
Plus 3 m/sec Gust Plus 50th percentile Shear 
Random qa/qp: FCS System Effects; 6 m/sec Gust 

(i.e., 9 m/sec Minus 3 m/sec) and Shear up to 99th Percentile 

Display qa/qp Envelopes: Basic Plus FCS Effects: 

Basic Plus 6 m/sec Gust and Shear Up to 99th Percentile 

Vehicle Dynamics 

• First 50 Bending Modes with 1% Damping 

• Aeroelastic Effects 

• Flutter Stability 

- First 20 modes 

- Control System Feedback Represented 

- Parametric Variation of Actuator Stiffness 

Failure Modes 

• Numbers 1 , 2, or 3 SSME Out Anytime After Lift-off 

• TVC Failure By-Pass Transient 


Analysis Tolerance 

± 0.02 deg/sec 
±0.12 deg/sec 
±0.1 5 deg/sec 
±10% 


None 


None 

None 

None 


Figure 98. Basic parameters (continued). 
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BASIC PARAMETERS 
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CHANT NO.: 

19 

(Continued) 

DATE 

APRIL 1986 


Analytical Approach Analysis Tolerance 


•Trajectory Logic Superimposes Engine-Out 
Squatcheloid on No-Failure Squatcheloid 

• Conduct Loads Survey Around Squatcheloid Using 
Rigid-Body Squawkr Program to Calculate Max/Min 
Wing and Eleven Loads and ORB/ET and SRB/ET 
Fitting Loads 

• Flexible-Body Dynamic Response Calculated for Final Loads 

Combination Method 

• qa/qp FCS Tolerance added (+ 700 psf-deg qa; ± 700 psf-<ieg qP) 

• 85% Gust Timed 6 sec After SSME Failure in 85% Max Shear 
or Full Gust 6 sec After SSME Failure Followed by Full 
Design Shear After SSME Failure. Sequence of Events 
Selected For Maximizing Loads 

• SRB Thrust Dispersions: 

• SD73-SH-0069-1 , -2, -3, and -4 (Structural Design Loads 
Data Book) 

• SD73-SH-0097-1 (Integrated Vehicle Flight Control System 
Data Book) 


Figure 98. Basic parameters (continued). 
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MARSHALL SPACE FLIGHT CENTER 

BASIC PARAMETERS 
Lift Off 


SRM Propulsion 

Analysis Tolerance 

• TC227A-75 Thrust Versus Time Curve Per SE-01 9-083-2H 

f 90 "F (ETR) 

(SRB Systems Data Book) For Max/Min Grain 
Temperatures (TC227H 1 Proposed as Update) 

\ 40 °F (WTR) 

•Thrust Level Development Uncertainty 

±3% 

• Steady-State Thrust Mismatch Between SRM’s 

35,000 lb 

• Flight-to-Fiight Thrust Level Uncertainty 

f ± 5% Single Motor 
\ ± 4.9% Both Motors 

•Thrust Buildup Rate Development Uncertainty 

Ref: SDIL SRM76-037 

•Thrust Misalignment 

± 0.50% (Both); 0.707" (One) 

Aerodynamics 

• Ground Wind Drag Coefficients Per SD72-SH-0060-2 
(Mated Vehicle Aero Design Data Book) and 
Rockwell Internal Letter SAS/AERO/75-430 

None 

Main Propulsion 

• 3 SSME's at 100% Thrust (RPL) to 109% Thrust (RPL) 

None 


Figure 99. Liftoff load parameters. 
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Lift Off 


DATE 

APRIL 1986 

Mass Properties 



Analysis Tolerance 

• Minimum Payload of 2,500 lb (Mission 3B) 


None 


• Maximum Payload of 32,000 lb (Mission 3A) 


None 


• Maximum Payload of 65,000 lb (Mission 3A) 


None 


Miscellaneous 





• SRB/MLP Holddown Bolt Preload (750,000 lb) 


None 


Flight Control and Guidance 





• Rockwell Control No. 7 Per SD73-SH-0047-1 
(Integrated Vehicle Flight Control System 
Data Book) 


None 


• All Nozzles Gimbal But SRB Nozzle Gimbal 
Limited to 2° for First 5 sec 

< 

r ±0.17* (SRB) 

[ +0.23' (SSME) 

• SRB Mistrim to 0° Until SSV Clears the Launch 
Pedestal 


None 


• STB TVC Misalignment 



2 o RSS Each SRB in 
Worst Direction 

External Environment 





• 95% Wind Speed (One Hour Exposure) 


None 


• Peak Wind Speed 



24 Knots (Max) 

• Tuned Gust (Worst Case) 



None 



Figure 99. Liftoff load parameters (continued). 
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ORGANIZATION 

MARSHALL SPACE FLIGHT CENTER 

NAME 


SYSTEMS DYNAMICS 
LABORATORY 

BASIC PARAMETERS 


R. RYAN 

CHART NO.: 

22 

LlftOff 

DATE 

APRIL 1986 


Vehicle Dynamics Analysis Tolerance 


• First 50 Bending Modes with 1% Damping 

Failure Models 

• None 

Analytical Approach 

• Digital Simulation of Vehicle Flexible Body 
Response Due to Applied Forces and Release of 
Base Constraints 

Combination Method 

• Sequence of Events Selected or Max Loads (WOW) 

• RSS Similar Uncertainties as a Group Then Add Groups 
(± 2 a Deviations) in Worst-On-Worst Combination 

Documentation of Results 

• SD73-SH-0069-1 , -2, -3, and -4 Structural Design Loads 
Data Book 


Figure 99. Liftoff load parameters (continued). 
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APPENDIX C— GLOSSARY 


Glossary Format: The glossary is divided into two sections. The first section is an alphabetical index of all 
terms, which identifies a group number where the definition is located. The definitions are given in the 
second section, grouped together with related terms to help clarify the definitions. 

C.l Alphabetical Index 


Term 


Located in Group No. 


Attributes 

Balancing Act 

Critical design review (CDR) 

Compartmentalization 

Component 

Concept selection 

Conceptual design 

Conduits 

Constraints 

Design certification review (DCR) 

Derived requirements 

Design cycle 

Design function 

Design phases 

Design stages 

Detail design 

Element 

Formal integration 

Flight readiness review (FRR) 


2 

4 

1 

3 

3 

1 

1 

6 

2 

1 

2 

1 

3 

1 

1 

1 

3 

4 
1 
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Gates 2, 6 

Informal integration 4 

Ixl matrix ® 

Life cycle attributes 2 

Manufacturing stage 1 

Margin 5 

Mission concept review (MCR) 1 

Metrics 2 

Minidesign cycle 1 

Mission statement 2 

NxN matrix 6 

Operations 1 

Parameters (design) 5 

Part ^ 

Parts of a system 3 

Performance 2 

Phases (of design) 1 

Planes 6 

Preliminary design 1 

Preliminary design review (PDR) 1 

Reintegration 3 

Requirement allocation 3 

Requirements 2 

Risk assessment 4 

Sensitivity 5 

System requirements review (SRR) 1 

Stages (of design) 1 
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1 


Subprocesses 

Sub-subsystem 3 

Subsystem 3 

System 3 

Systems integration and verification 1 

Tasks 6 

Technical integration 4 

T-model 4 

Technology Readiness Level (TRL) 2 

Uncertainty * 

Verification 1 

Work breakdown structure (WBS) 6 
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C.2 Definitions 


GROUP 1 

Design stages. The design stages consist of conceptual design, preliminary design, detailed design, 
manufacturing, and systems integration and verification. These design stages are followed by the operational 
stage. 

Design phases. Historically, there have been five design phases that have been replaced by the design 
stages defined above. 


• Phase A — Preliminary analysis 

• Phase B — Definition 

• Phase C — Design 

• Phase D — Development 

• Phase E — Operations. 

Subprocesses. There are four “provide aerospace products and capabilities” subprocesses. 

• Formulation — Define program 

• Approval — Determine program readiness 

• Implementation — Deliver program products and/or capabilities 

• Evaluation — Assess the ability of program to meet its technical and programmatic commitments. 

Conceptual design. That part of the design process where many feasible alternative concepts are determined 
for detailed study. It occurs early in the process when only top-level system parameters are known. 
Multicriteria decision-aiding techniques are used to reveal the best alternatives (could be a single alternative) 
from the many proposed concepts. The down-select decision is based on performance, cost, schedule, reliability, 
safety, operability, design uncertainty, and TRL figures of merit obtained from trade and sensitivity studies. 

Preliminary design. This part of the design process follows conceptual design, and its purpose is to determine 
which of the selected alternative concepts is the best and then to establish a baseline design concept. In this 
stage, the configurations are further matured, and the significant subsystems are designed for inclusion in 
the assessment. In addition, refined analyses, simulations, and tests data are developed for trade and sensitivity 
assessments. All system support, manufacturing, test, and operations requirements are also defined. Refined 
and updated multicriteria decision-aiding techniques are used to reveal the best configuration based on 
performance, cost, schedule, reliability, safety, operability, and design uncertainty data obtained from trade 
and sensitivity studies relating to the launch vehicle, all supporting activities, and all supporting systems. 
This downselected configuration then becomes the baseline for detail design. 

Detail design. During this part of the design process, the goal is to provide an engineering description 
(drawings, specifications, plans, etc.) of a tested and producible design. Additionally, plans are updated for 
final development, manufacturing, verification, and operations. 
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Manufacturing. During this part of the process, flight, facility, and GSE hardware and software are 
developed, manufactured/coded, and documented. 

Systems integration and verification. This is the final stage of vehicle development. All systems (hardware 
and software) associated with the vehicle and operations are assembled, tested, and checked for compatibility, 
functionality, and verification that the design requirements and constraints are satisfied and the system is 
flight ready. All results are documented including anomalies and lessons learned. 

Operations. Operations consists of two parts. The first part pertains to vehicle development. It is here that 
it is determined if the launch vehicle satisfies the mission need statement or not. If it does not, then flight 
constraints are required. The second part of operations occurs after all the flight constraints are determined. 
Then routine operations are established which include evaluation of results and documentation of anomalies 
and lessons learned. 

Concept selection. Many alternative concepts are developed early in the design process. Initially, concepts 
are conceived, evaluated, and rejected or accepted based upon top-level system requirements. Multicriteria 
decision-aiding techniques are used to reveal the best alternatives from the many proposed concepts. The 
downselect decision is based upon discriminators such as performance, cost, schedule, reliability, safety, 
operability, design uncertainty, and TRL figures of merit obtained from trade and sensitivity studies. As the 
design process proceeds, additional knowledge related to the discriminators is acquired through analyses, 
simulations, and tests. This additional knowledge is applied with the multicriteria decision-aiding technique 
at various levels of system maturity until one concept is finally selected. The final concept selection usually 
occurs during or around PDR; however, some have occurred immediately after conceptual design. Then 
the selected concept proceeds to final design, development, and operations. 

Design cycle. Each stage (e.g., conceptual design, preliminary design, etc.) of the design process is completed 
in a number of design cycles (iterations). For each design cycle during a particular design stage, the discipline 
functions develop knowledge and reduce risk (design uncertainty) through analyses, simulations, and testing 
at increasing levels of penetration as the design process proceeds from the conceptual design through the 
systems integration and verification stages. Through the process of formal and informal technical integration 
for each design cycle, the attributes determined by the design functions via the discipline functions are 
assessed at the system level. The focus of the assessment is conformance of the attributes to the overall 
system-levied requirements, constraints, philosophy, procedures, criteria, ground rules, etc., as well as 
their balance, interactive compatibility, consistency, and associated data trends. If the attributes are not 
consistent with the aforementioned and/or the appropriate level of maturity and risk has not been achieved, 
then another cycle is initiated and the design process repeated until a set of appropriately matured and 
balanced attributes with the required level of risk is achieved. At the initiation of each design cycle there 
could be changes in the requirements, constraints, philosophy, procedures, criteria, ground rules, etc., based 
upon results from the previous cycle. 

Minidesign cycle. If a problem is indicated by analyses, simulations, testing, manufacturing, assembly, 
operations, etc., then after assessment, a redesign may be required. If the redesign is of a localized nature 
and does not impact the entire system, then the appropriate design and discipline functions execute the 
redesign also without perturbing the entire system. Technical integration can be accomplished via a change 
request guaranteeing that all the appropriate requirements are satisfied and balanced. 
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Mission concept review (MCR). First formal review. Assesses mission objectives and concepts along 
with functional and performance requirements. 

System requirements review (SRR). Demonstrates that the mission and system requirements are defined 
and understood. In addition, management techniques, procedures, agreements, etc., are evaluated. 

Preliminary design review (PDR). Conducted when the basic design approach has been selected. 
Demonstrates that the preliminary design meets all the system requirements with acceptable cost, schedule, 
and technical risk. The design drawings are about 10 percent complete. The results of successful review are 
the “design to” baseline and the authority to proceed to final design. 

Critical design review (CDR). Verifies that the design meets all the requirements and establishes a baseline 
for manufacturing. The design drawings are about 90 to 95 percent complete. The results of a successful 
review are the “build to” baseline and approval of the production and verification plans. 

Design certification review (DCR). Evaluates the “as-designed” results from verification analyses, tests, 
and simulations to certify the design. Determines what requirements were met, reviews significant problems, 
and assesses corrective actions. This review is usually conducted after the manufacturing, assembly, and 
verification process. 

Flight readiness review (FRR). Certifies that the system is flight ready and all flight objectives can be 
accomplished. This includes the launch vehicle, operational system, and all associated teams. 

GROUP 2 

Mission statement. The fundamental statement of need for a system; for example, a basic requirement for 
a launch vehicle to deliver xxx pounds of payload to a specified orbit at a reliability of at least yyy for a cost 
not to exceed $zzz. 


Requirements. The conditions that the designed system must meet. Requirements specify what attributes 
the system must have. Requirements are “equalities;” that is, they require that the specified attribute equal 
a certain value. In more general usage, requirements are taken to mean the combined set of requirements, 
constraints, and derived requirements. 

Constraints. The conditions that the designed system must be less than or must be greater than. Constraints 
are “inequality requirements” in that they require that the specified attribute be less than or greater than a 
certain value. Another type of constraint is that the TRL of any technology used in the design be greater 
than a specified TRL. 

Derived requirements. Requirements or constraints that are not top-level requirements associated with 
the mission statement but which are created during the design process as a result of designing to meet the 
top-level requirements. They may be identified by a design function or discipline to be imposed on itself, 
or to be imposed on others. 
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Attributes. Properties of the designed system or subsystem. These may be performance properties, cost, 
reliability, etc. An attribute is a property that can be compared with a requirement or a constraint. 

Performance. In this document, performance typically means the physical behavior of the launch vehicle 
or its subsystems, where that physical behavior has an effect on meeting the physical requirements imposed 
on the vehicle. Examples of measures of performance include payload-to-orbit, mass fraction, specific 
impulse of the propulsion subsystem, TPS mass density, etc. Performance is a physical attribute (or attributes) 
of the launch vehicle which is distinct from the life cycle attributes of cost, safety, reliability, operability, 
etc. Note also that this definition of performance is broader than the conventional usage of performance to 
strictly mean payload-to-orbit. 

Life cycle attributes. Vehicle attributes other than performance as defined above. Life cycle attributes 
include cost, safety, reliability, operability, etc. 

Technology Readiness Level (TRL). The maturity of a given technology, as measured by NASA’s TRL 
scale; values ranging from 1 (least mature) to 9 (most mature). 

Metrics. As used in this document, metrics are quantifiable measures of attributes (see following note). 

(Note: “Quantifiable measure of attributes” is a definition of metrics applied in the recent past and applied 
in this document. There is, however, a move in the engineering community to apply specific definitions to 
certain parameters that quantify the system (see reference 19). In the past some of these terms have been 
used interchangeably. Specifically, three of these terms are (1) figures of merit, (2) technical performance 
measures (TPM’s), and (3) metrics. In reference 19, figures of merit are used to quantify requirements. 
TPM’s are used to track the progress of design and manufacturing. Metrics are measures related to the 
process, not the product.) 

Gates. Events in the design process where an attribute of the design is compared with a requirement or 
constraint. To pass the gate, the design’s attribute must meet the requirement or constraint; if it does not, 
the design must be changed or the requirement/constraint must be relaxed. 

GROUP 3 

Parts of a system. A system can be compartmentalized into parts. Usually this follows a hierarchy of 
compartmentalization into smaller and smaller parts. Generically, the system is compartmentalized into 
subsystems; the subsystems are compartmentalized into sub-subsystems, etc. Sometimes the various levels 
of the hierarchy are given specific names, such as in the following examples which are not unique. 


Level 

System 

Subsystem 

Element 

Component 

Part 


Specific Name 

Launch vehicle 
Propulsion 
Liquid engine 
Turbopump 
Turbine blade 
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Design function. The activity of creating a design for a specific subsystem or system. The primary products 
of a system (top plane) design function are the specifications and drawings for its subsystem or system. 
The primary products of the other design functions (lower planes) are the descriptions of their respective 
aspects of the design, as fed to the system plane. See also the discussion in section 4.3.1. 

Discipline function. The activity such as analysis, simulation, testing, etc., that is performed during the 
design process by specialists in the various technical areas of expertise. See also the discussion in 
section 4.3.1. 

Compartmentalization. Separation of the design process into managable parts. There are three types of 
compartmentalization: (1) Separation of a system into subsystems (subsystems can be further 
compartmentalized into sub-subsystems); (2) separation of the design functions for each subsystem; and 
(3) separation of the design functions into the discipline activities necessary to achieve the design. 

Reintegration. The process of recombining the compartmentalized parts of the design process to form a 
complete system design. Discipline functions are reintegrated into design functions, design functions are 
reintegrated into subsystems, and subsystems are reintegrated into the total system. 

Requirement allocation. Identification and assignment of requirements by the system design function to 
the subsystems and lower design functions. Requirements are divided and allocated with the intent of 
producing a total design that will achieve the best balance among the subsystems and requirements. 

GROUP 4 

Technical Integration. The interactive activity among all participants in the design process, whereby the 
compartmentalized parts reintegrate into a balanced, successful total design. Technical integration is 
enabled by formal and informal information flow methods, by a system focus of all participants on how 
their part affects the total system, and by leadership that continually ensures that interactive aspects of the 
design are being addressed and balanced. 

T-model. A representation of technical integration that consists of three parts. The horizontal crossbar 
portion of a “T” can be visualized as consisting of two parts as a result of a horizontal subdivision. The 
upper portion of the subdivision represents formal integration. Formal integration is accomplished by the 
leader via the systems plane. The lower portion of the crossbar represents informal integration. Informal 
integration is accomplished by design and discipline functions. The third portion of the T-model is the 
vertical leg of the T. This represents the activities of discipline engineers, and it signifies their indepth 
discipline capability with a systems perspective. 

Formal Integration. A communication activity that consists of interactions between the system design 
function and all other design functions. It ensures that the attributes and uncertainties (developed by the 
design functions) satisfy the requirements, constraints, etc., and they are compatible. An associated activity 
of formal integration is resolving engineering conflict between design functions when incompatibilities, 
inconsistencies, unnecessarily high interactions and sensitivities, etc., occur. These activities are 
accomplished by the leader via the system plane. 
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Informal Integration. A communication activity that consists of interactions among discipline functions 
in a design function and interactions between design functions. The focus of these activities consists of 
data and information exchanges to determine the attributes and their uncertainties associated with the 
design function planes in an efficient and accurate manner. 

Balancing Act. There are two types of balancing acts. The first relates to the system where the program 
requirements are balanced by the launch vehicle design and the operational design. The second relates to 
interactive discipline and design activities where trade balances are made among the subsystems, design 
functions, and disciplines to achieve the required attributes with acceptable uncertainties. 

Risk Assessment. An evaluation process that addresses technical, cost, and schedule risk. It uses an estimate 
of probabilities of success versus consequences of failure. 

GROUP 5 

Parameters (design). Design measures that fall into two categories: (1) One that the designer can control 
and (2) one that the designer cannot control. The controllable parameters are measures that characterize the 
design; e.g., independent variables of the design process. The latter parameters are environmental inputs 
where the designer has control only over how they are characterized. 

Uncertainty. A general term for the estimated amount by which the observed or calculated value of a 
quantity may depart from the true or mean value. 

Sensitivity. A measure of a system of functional relationships, a hardware system, or a software system 
that can be defined as the amount that the dependent variables differ from their reference values (baseline) 
when one of the independent variables differs from its reference value (baseline). The specific calculus 
depends upon the application. 

Margin. The difference between the value that a variable must not exceed (its requirement limit) and the 
predicted maximum value of that variable, including known parameter variations. Margin is the measure 
of headroom available in meeting the requirement, and may be included to allow for contingencies or 
unmodeled uncertainties. 

GROUP 6 

Planes. In the design process model delineated in this document, a plane represents a design function. The 
plane contains the various activities that are executed within the design function. 

Conduits. Pathways between planes that represent information flow among the design functions. 

Gates. Events in the design process where an attribute of the design is compared with a requirement or 
constraint. To pass the gate, the design’s attribute must meet the requirement or constraint; if it does not, 
the design must be changed or the requirement/constraint must be relaxed. 

Tasks. Specific activities accomplished by design functions or discipline functions. 
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Ixl matrix. A matrix that defines information flow among subsystems and between a subsystem and its 
next higher level system. Interface inputs, outputs, and connectivity are shown. 

NxN matrix. A matrix that defines information flow among design functions and disciplines, showing 
inputs, outputs, and connectivity. 

Work Breakdown Structure (WBS). An organized listing of the areas of work (tasks) required to produce 
a design. 
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